云计算之路-阿里云上-幸福没那么容易:“黑色1秒”又出现了

“幸福没有那么容易,才会特别让人着迷”,这是黄小琥的《没那么简单》中的一句歌词。

这句歌词或许最能表达我们此刻的心情——在我们宣布“黑色1秒”问题已解决的第二天,“黑色1秒”竟然再次出现!

昨天早上8点左右起床后,睡眼惺忪地查看服务器的实时监控,打算欣赏一下“黑色1秒”被消灭后那漂亮的QPS曲线。突然,一个即将被最新曲线覆盖的锯齿闪现在眼前——黑色1秒!不会吧?怎么会?这不是真的,或许是自己迷迷糊糊弄错了服务器,或许是自己余梦未醒?。。。

当时真的不敢相信,以为是自己什么地方弄错了。所以,继续紧盯着服务器进行观察,观察了一个上午也没有出现。虽然没出现,但心里却很忐忑,一边是“可能是当时弄错了”的侥幸心理,一边是频繁闪现在脑海里的“黑色1秒”身影。

继续观察,下午14:23出现的“黑色1秒”无情地摧毁了所有的侥幸。。。

接下来在14:45与18:01也观察到了黑色1秒。

就这样,我们在云上坐了一次“幸福”的过山车,从“幸福总是很突然”到“幸福没那么容易”。

由于我们对解决“黑色1秒”的急不可耐,过早地确认了“黑色1秒”问题的解决,浪费了很多关注这个问题的朋友的感情,在此说声抱歉!

带着失落与愧疚,从过山车上下来之后,我们别无选择,只剩下自己力所能及的最后一招——实现.NET的跨平台,将Web服务器由Windows换成Linux,即使战胜不了“黑色1秒”,也可以躲过它。但这一招是否有效有一个前提,那就是Linux上没有“黑色1秒”问题,这个我们无法验证,只能为云上的幸福赌一把了。

时间: 2024-12-10 20:54:17

云计算之路-阿里云上-幸福没那么容易:“黑色1秒”又出现了的相关文章

云计算之路-阿里云上-幸福总是很突然:“黑色1秒”问题解决啦

前几天发生了2件神奇的事情:一是1位园友在阿里云上遇到了和我们一模一样的“黑色1秒”问题:二是阿里云推出了IO优化的基于KVM架构的服务器,据说理论上可以解决“黑色1秒”问题.很巧的是,这2件事情竟然开始于同一天. “黑色1秒”问题是我们在阿里云上遇到的最神妙莫测,也是折磨我们时间最长的一个问题.它于2014年5月8日被发现,一直折磨我们到现在,这一年多我们只能依靠“每天重启应用程序”过着云上的“幸福”生活. (“黑色1秒”最显著的特征:QPS为0) 折磨我们到现在,我们也与之斗争到现在.虽然我

云计算之路-阿里云上:对“黑色n秒”问题的最终猜想——CPU C-states引起的

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

云计算之路-阿里云上:什么是“黑色1秒”?

为了更好地分享我们解决"黑色1秒"问题的过程,在这篇博文中我们将专门描述一下"黑色1秒"问题的表现. "黑色1秒"是我们使用阿里云以来继"黑色10秒"之后遭遇的最奇特.最诡异.最难以捉摸.最富有戏剧性的问题. 它有2个最显著的特征: 第一个是最直观的表现,在Windows性能监视器(Performace Monitor)中会出现1秒的ASP.NET Applications -> Requests/Sec(简称QPS)为

云计算之路-阿里云上:消灭“黑色n秒”第二招——给w3wp进程指定CPU核

虽然昨天的第一招失败了,但是从失败中我们学到了与多核CPU相关的Processor Affinity(处理器关联)的知识. 既然我们可以让.NET程序的不同线程运行于指定的CPU核,那是不是也可以让IIS应用程序池的进程w3wp运行于指定的CPU核? 虽然看起来"黑色n秒"似乎与w3wp运行于哪些CPU核没有什么关系,但是我们既然把怀疑对象锁定在CPU,那么任何与CPU相关的线索都不能放过.即使失败,也会满载而归,因为如果没有"黑色n秒"这个问题的驱动,我们根本不会

云计算之路-阿里云上:“黑色1秒”问题与2009年Xen一个补丁的故事

在之前对"黑色1秒"问题的分析博文中,我们将最大嫌疑对象锁定在了Xen,在这篇博文我们将从Xen的角度进行分析.也许有人会问,为什么不知道天多高地多厚地去研究不属于自己范围的问题?只因我们对一个问题的强烈好奇心--究竟是不是我们用Windows的错? 2009年3月20日,来自Intel的Yu Ke通过Xen-dev Mailing List给来自Citrix的Keir Fraser(负责的Xen开发者之一)发了一封邮件,提交了Xen的一个patch--cpuidle: suspend

云计算之路-阿里云上:消灭“黑色n秒”第三招——禁用网卡的TCP/IP Offload

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

云计算之路-阿里云上:读取缓存时的“黑色0.1秒”

看到标题中的"0.1秒",你也许会呲之以鼻:不会吧,0.1秒也要计较,不是吃饱撑着,是没吃饱也撑着. 依然没撑着!在memcached应用场景中,响应速度是处于1ms级别的,0.1s可是比1ms慢了100倍啊. 如果你不相信1ms级别,请看这篇文章(微博CacheService架构浅析)中的一段话: 目前微博平台部分业务子系统的Cache服务已经迁移到了CacheService之上,它在实际的运行过程中也取得了良好的性能表现,目前整个集群在线上每天支撑着超过300W的QPS,平均响应耗

云计算之路-阿里云上:神奇的“黑色30秒”再次出现,究竟是谁的错?

自从4月28日我们从ASP.NET线程的角度对"黑色30秒"问题进行分析之后,我们采用了新的线程设置,然后观察"黑色30秒"是否再次出现. <processModel enable="true" requestQueueLimit="5000" maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50&q

云计算之路-阿里云上:SLB会话保持的一个坑

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