在昨天针对“黑色30秒”问题的分析中,我们猜测Requests Queued上升是由于正在处理的请求出不去(到达不了客户端).今天我们结合IIS日志验证这个猜测. IIS日志中有一个重要的指标——time-taken,time-taken不仅包含了请求在服务端执行的时间,还包含了响应的内容从服务端到达客户端的时间(详见以下的引用内容). Beginning in IIS 6.0, the time-taken field typically includes network time. Befo…

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

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

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

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

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

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

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

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

在昨天的博文(云计算之路-阿里云上:读取缓存时的“黑色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…

7月10日11:14接到一位用户反馈,访问园子时加载不了 common.cnblogs.com/script/jquery.js 这个文件. 由于这个域名用了阿里云CDN,所以我们判断可能是某个CDN节点出了问题,准备让这位用户ping common.cnblogs.com将CDN节点的IP反馈给我们.恰好这时我们也遇到了同样的问题,浏览器长时间停留在连接common.cnblogs.com的状态中: 然后ping common.cnblogs.com,ping包的响应速度很快,看来不是部分CD…

我们从今年6月开始在生产环境进行 docker 容器化部署,将已经迁移至 ASP.NET Core 的站点部署到 docker swarm 集群上.开始我们选用的阿里云容器服务,但是在使用过程中我们遭遇了恐怖的路由服务(acsrouting)路由错乱问题 —— 请求被随机路由到集群中的任一容器,虽然后来阿里云修复了这个问题,但我们对容器服务失去了信心,走上了用阿里云服务器自建 docker swarm 集群的道路. 用上自建 docker swarm 集群之后,本以为可以在云上容器中过上安稳的日…

这篇博文记录一下6月1日在阿里云上遇到的奇怪的CPU 100%问题,希望多年以后能真相大白. 那天负载均衡(SLB)中只放了1台云服务器(平时都放2台),由于是节假日,虽然只放了一台,但这台服务器的负载也没有平时高.但在上午的时候突然出现了CPU 100%问题,然后切换到另外一台云服务器恢复正常. 下午的时候,我们将负载又切换回那台出问题的服务器,正常运行一段时间后,CPU又飙到100%.切换回之前正常的那台服务器后又恢复正常. 对比两台服务器,虽然那台正常的服务器CPU波动也挺大,但即使偶尔串…

你知道在我们使用的云服务器中哪台最贵吗?跑memcached的缓存服务器(12G内存).你知道保证网站访问速度的功臣之一是谁吗?跑memcached的缓存服务器. 用云服务器这么高贵的内存跑memcached实在太奢侈了,我们一直忐忑不安,但也没有其他选择.现在终于等来了阿里云开放缓存服务OCS,今天晚上完成了部署. 下面分享一下我们的部署过程: 我们之前用的Memcached .NET客户端 EnyimMemcached 就是OCS推荐的.NET客户端,所以应用程序无需作任何修改,只需修改一下…

当今天早上在日志中发现这样的错误之后,对阿里云OCS(mecached缓存服务)的积怨倾泻而出. 2014-06-08 07:15:56,078 [ERROR] Enyim.Caching.Memcached.MemcachedNode System.IO.IOException: Failed to write to the socket '10.160.124.220:11211'. Error: ConnectionReset 这个问题我们4月份发现过,当时给OCS起了个外号叫“会断连接的…

如果说2013年云计算之路的主题是“踩坑”,那么2014年我们希望云计算之路的主题变成“填坑”——当然填坑是阿里云来完成的,我们只是见证曾经的坑坑洼洼变成平坦大道. 15号(周四)晚上我们发现了SLB会话保持的坑,16号晚上阿里云成功定位并进行修复,这两天正式发布后会填平这个坑.这次从踩坑到填坑的过程是最痛快的一次. 接下来我们的目标锁定在“黑色n秒”(刚发现一个英文说法:stuck for x seconds)这个坑我们最多.最神秘.最诡异的坑. 受“云计算之路:2009年Xen一个补丁背后那…

在之前对“黑色1秒”问题的分析博文中,我们将最大嫌疑对象锁定在了Xen,在这篇博文我们将从Xen的角度进行分析.也许有人会问,为什么不知道天多高地多厚地去研究不属于自己范围的问题?只因我们对一个问题的强烈好奇心——究竟是不是我们用Windows的错? (注1:文中所说的Xen补丁问题只是提供一种分析问题的思路,我们遇到的“黑色1秒”问题与有没有打这个补丁没有关系) (注2:关于这个Xen补丁背后的故事,推荐阅读阿里云分享的博文:云计算之路:2009年Xen一个补丁背后那不为人知的故事) 2009…

程咬金有三板斧,我们有三招.在这篇博文中我们要出第三招,同时也意味着昨天在“希望的田野”上的第二招失败了. 前两招打头(CPU)不凑效,这一招要换一个部位,但依然要坚持攻击敌人最弱(最忙最累)部位的原则.那除了CPU,最忙最累的部位是哪里呢?对于Web服务器来说,毫无悬念,当然是网卡.而且阿里云的云服务器,所有的网络负载都集中在一块内网网卡上,SLB(负载均衡)用它,OCS(缓存服务)用它,RDS(数据库服务)也用它.所以,就对它出招! 招式受这篇博文(XenServer – Windows 2…

在上周六遭遇阿里云容器服务 swarm 版的故障之后,我们决定还是走自建 docker swarm 之路,只要不是阿里云底层的问题,我们相信会找到办法解决或避开自建 docker swarm 不稳定的问题. 以下是我们即将采用的 docker swarm 集群部署优化措施. 1)2 个 overlay 网络合并为 1 个,以减少维护多个 overlay 网络的开销 之前用了 2 个 overlay 网络 cnblogs 与 proxy ,路由容器 docker-flow-proxy 只加入 pr…

在发现云服务器读取OCS缓存的“黑色0.1秒”是发生在socket读取数据时,而且是发生在读取开始的字节,甚至在socket写数据时(比如写入缓存key)也会出现超过50ms的情况,我们的好奇心被激发到一个新的高度. 根据我们的实测,在云服务器上创建一个新的TCP连接通常也不过3ms左右.在黑色0.1秒期间,TCP包已经到达网卡,从网卡读到内存中竟然超过100ms,这太不可思议了!后来想想,如果.Net或Windows存在这样的问题,那微软就不是全球第一大软件公司,而是全球第一大忽悠公司,这个可…

2013年7月24日,18:20~18:50左右,处于阿里云云服务最前沿的SLB(负载均衡)出现故障,造成了网站不能正常访问(由于是最前沿,这次连502也看不到了). 在大家对昨日RDS故障带来的麻烦还记忆犹新的时候,今天又给大家带来新的麻烦,我们真的真的很抱歉! 我们本来想走上云计算之路之后,可以更专心于开发出更好的产品,为大家提供更好的服务,哪知道国内云计算厂商连云计算的根本——稳定性都不能保证. 在艰苦走了一段云计算之路之后,突然发现面前竟然是一条十字路口:国内云计算厂商的不争气,国外云计…

大家好,非常抱歉!今天10:28-10:51期间由于阿里云云盾流量清洗,以及切换IP后负载均衡的带宽跑满,影响了主站的正常访问,给您造成了很大的麻烦,请您谅解! 故障的过程是这样的: 10:28,我们收到了来自阿里云云盾的通知短信: [阿里云]尊敬的用户:您的 IP 遭受外部流量攻击,已启动免费清洗服务... 以前也收到过几次这样的通知短信,根据以往的经验,这样的云盾流量清洗不会影响网站的正常访问. 可是今天收到短信后,突然发现主站www.cnblogs.com不能访问了(当时我们是通过上海电信…

非常抱歉!今天 12:03-12:52 ,由于数据库连接数异常突增超过1万,达到了阿里云RDS的最大连接数限制,影响了全站的正常访问.由此给您带来麻烦,请您谅解. 在发现数据库连接数突增的问题后,我们一开始怀疑可能是我们的某些应用中产生太多ADO.NET连接引起的,但是对嫌疑的应用们进行重启后,连接数依然高居不下. 后来,我们回想起去年9月份遇到的一次数据库问题,当时很多数据库查询超时,IOPS突增达到RDS的最大限制.开始我们也是从应用层面下手,但怎么也解决不了,后来实在没办法,试了试主备库切…

在昨天的博文中,我们坚持认为数据库连接数过万是阿里云RDS的问题,但后来阿里云提供了当时的数据库连接情况,让我们动摇了自己的想法. 帐户 连接数 A 4077 B 3995 C 741 D 698 E 519 上面这5个帐户产生了10030个数据库连接,当看前4个帐户(产生了9511个连接)的名称时,我们打了一个寒颤 —— 这些都是运行 Linux 上的 ASP.NET Core 站点...这不是巧合,其中必有蹊跷. 随后,我们观察了主备库切换后的 RDS 中数据库连接情况.有一个运行在 Lin…

最近陆续有用户反馈在我们网站上登录时遇到登录死循环问题.输入用户名与密码提交后,显示登录成功,但跳转到目标网址后(由于依然处于未登录状态)又跳转回登录页面,再次登录,再次这样...就这样一直循环,怎么也登录不进去. 排查了几天,从我们自身的角度实在找不到线索.昨天不得不把怀疑的目光转向阿里云负载均衡 —— 可能是负载均衡的某种网络问题造成浏览器没有接收到有效的登录Cookie,换个负载均衡试试.我们联系了持续被这个问题困扰的用户,得知她用的是联通的线路上网的,于是我们创建了新的负载均衡,将联通线…

继5月13日下午被攻击之后,今天下午,攻击又肆无忌惮地来了,14:35.14:39.14:40.14:41 ,依次有4个IP遭遇超过30G的流量攻击,被阿里云“云盾”关进“黑洞”,造成被攻击IP上的站点无法正常访问...15:11左右全部恢复正常. 受此次攻击影响的站点有:www.cnblogs.com ,q.cnblogs.com ,news.cnblogs.com,home.cnblogs.com ,job.cnblogs.com ,kb.cnblogs.com ...,由此给您带来很大的麻…

非常抱歉,今天下午14:20-14:55期间,由于同一个负载均衡中的2台服务器都出现CPU 100%问题,造成博客后台无法正常访问,由此给您带来了很大很大的麻烦,请您谅解. 博客后台是CPU消耗很低的应用,这2台服务器通常CPU占用在5%左右,之前从来没有出现CPU 100%的问题(所以连云监控都没添加CPU监控报警).这次问题很突然,我们发现问题后,远程连接不上服务器,只能重启,重启后立马恢复正常. 对于问题的具体原因,目前还没找到.我们正在进一步排查,也反馈给了阿里云,阿里云也在排查.…

2017年12月29日 10:18 ~ 11:00 左右,由于整个 docker swarm 集群宕机,造成我们迁移至 .net core 跑在 docker swram 上的所有站点无法正常访问,由此给您带来很大很大的麻烦,请您谅解.受这次故障影响的站点有 闪存,博问,班级,园子,短信息,招聘,小组,openapi ... 2017年,随着将一个一个项目从 .net framework 迁移至 .net core ,我们兴奋地在部署上迈出了重要的一步——终于可以进行 docker 部署了.对于…

在上次遭遇 docker swarm 集群故障后,我们将 docker 由 17.10.0-ce 升级为最新稳定版 docker 17.12.0-ce . 前天晚上22:00之后集群中的2个节点突然出现CPU波动,在CPU波动之后,在凌晨夜深人静.访问量极低的时候,整个集群出现了故障,访问集群上的所有站点都出现了502,过了一段时间后自动恢复正常. ECS实例:swarm1-node5,CPU百分比于00:52发生告警,值为96.14%,持续时间0分钟 ... 昨天早上发现访问部分节点中的容器应…