(上图是今天出问题期间Web服务器性能监控图,紫色表示的是Request Execution Time) 昨天我们发布了一篇博客分享了我们这两天遇到的OCS(开放缓存服务)问题,详见云计算之路-阿里云上:愚人节被阿里云OCS愚. 后来,阿里云确认了问题的原因:在OCS升级过程中造成了写入的缓存数据过期时间丢失,只需删除这些有问题的缓存数据就不会再出现这个问题. 今天一大早访问低峰的时候,我们进行了清空OCS实例缓存的操作,解决了OCS缓存不能过期的问题. 今天中午11:30左右,园子访问速度突然…

3月21日,由于使用阿里云服务器自建 docker swarm 集群的不稳定,我们将自建 docker swarm 集群上的所有应用切换阿里云容器服务 swarm 版(非swarm mode). 3月22日,我们进行移除与重启节点的操作时引发了故障,详见 云计算之路-阿里云上-容器服务:移除节点引发博问站点短暂故障 . 3月24日,我们参考阿里云容器服务帮助文档-指定多节点调度通过给节点添加用户标签的方式成功移除了部分节点.我们是这么操作的,当时所有节点没有添加用户标签,给待移除节点之外的所有节…

冒着被大家厌烦的风险,今天再发一篇“云计算之路-阿里云上”.这是在前一篇发过之后真实发生的事情,我们觉得定位问题的过程值得分享.而且估计园子里不少朋友被这个问题骚扰过,我们有责任让大家知道问题的真正原因. 快下班之前,园区里另外一家公司的朋友说他们公司有的人不能正常访问园子——会出现HTTP Error 400错误,而其他人可以正常访问.这个问题立即引起了我们的警觉,因为之前也有园友反馈过同样的问题,当时什么也没动,后来就好了,以为是他们公司网络代理服务器的问题.由于我们从未遇到过这个问题,而且…

今天是愚人节,而我们却被阿里云OCS愚,很多地方的缓存一直不过期,造成很多页面中的数据一直不更新.这篇博文将向您分享我们这两天遇到的OCS问题. 阿里云OCS(Open Cache Service)是阿里云提供的开放缓存服务,简单来说就是一个巨大的memcached.我们是从2013年12月12日开始使用阿里云OCS的(详见云计算之路-阿里云上:用上了开放缓存服务OCS).OCS是保证网站性能的最重要的功臣之一,而随着网站访问量的快速增长,OCS更加举足轻重.曾经有一个周末,我们因为清空了OCS…

在这篇博文中,我们抛开对阿里云的怀疑,完全从ASP.NET的角度进行分析,看能不能找到针对问题现象的更合理的解释. “黑色30秒”问题现象的主要特征是:排队的请求(Requests Queued)突增,到达HTTP.SYS的请求数(Arrival Rate)下降,QPS(Requests/Sec)下降,CPU消耗下降,Current Connections上升. 昨天晚上18:08左右发生了1次“黑色30秒”,正好借此案例分析一下. 1.为什么Requests Queued会突增? 最直接的原因…

今天下午访问高峰的时候,主站的Web服务器出现奇怪的问题,开始是2台8核8G的云服务器(ECS),后来又加了1台8核8G的云服务器,问题依旧. 而且3台服务器特地使用了不同的配置:1台是禁用了虚拟内存的临时磁盘云服务器,1台是启用了虚拟内存的临时磁盘云服务器,1台是禁用了虚拟内存的云盘云服务器.这样排除了磁盘IO与虚拟内存的原因. 问题的表现是这样的(以下监视截图来自Windows性能监控器Performance Monitor): 1. ASP.NET请求执行时间(Request Execut…

在云上真是无奇不有,昨天偶然间发现在IIS的应用程序池回收设置中,仅仅设置了一下基于虚拟内存限制的回收,就引发了CPU有规律的波动.在这篇博文中,我们将向大家汇报一下云计算之路上的这个小发现. 在之前我们使用阿里云云服务器(虚拟机)遇到一个左右为难的情况: 如果开启虚拟内存页面交换文件,会造成CPU占用高,在高并发情况下会引发CPU 100%.系统无响应的故障,详见云计算之路-阿里云上:启用Windows虚拟内存引发的CPU 100%故障. 如果关闭虚拟内存页面交换文件,在某种因素引起的短时间虚…

今天上午11:35~11:40左右,由于负载均衡中的两台云服务器CPU占用突然飚至100%,造成网站5分钟左右不能正常访问,请大家带来了麻烦,请谅解! (上图中红色曲线表示CPU占用) 经过分析,我们确认CPU 100%问题与启用Windows虚拟内存有关. 原先这两台云服务器是禁用虚拟内存的,但昨天由于虚拟内存不够用,造成了服务器自动重启(详见云计算之路-阿里云上:禁用Windows虚拟内存引发的重启),于是启用了Windows虚拟内存.在今天访问高峰期高并发的情况下,引发了CPU 100%故…

在昨天的博文(云计算之路-阿里云上:读取缓存时的“黑色0.1秒”)中我们犯了一个很低级的错误——把13ms算成了130ms(感谢陈硕发现这个错误!),从而对问题的原因作出了错误的推断,望大家谅解! 从中我们吸取到了一个教训:趁热打铁要小心,容易失去冷静,作出错误的判断. 今天我们痛定思痛,用了一个下午的时间重新分析了“黑色0.1秒”问题,这次从EnyimMemcached的源代码下手(https://github.com/enyim/EnyimMemcached). 怎么下手呢?我们用了最粗鲁.…

昨天(2013年8月6日)下午,承载www.cnblogs.com主站的两台云服务器分别自动重启了1次,由于这两台云服务器使用了负载均衡(SLB),重启并未影响网站的正常访问. 与这次重启相关的Windows事件日志如下: 云服务器1(8核CPU,8G内存): 14:36:22 —— Windows successfully diagnosed a low virtual memory condition. The following programs consumed the most vir…