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

前几天发生了2件神奇的事情:一是1位园友在阿里云上遇到了和我们一模一样的“黑色1秒”问题;二是阿里云推出了IO优化的基于KVM架构的服务器,据说理论上可以解决“黑色1秒”问题。很巧的是,这2件事情竟然开始于同一天。

“黑色1秒”问题是我们在阿里云上遇到的最神妙莫测,也是折磨我们时间最长的一个问题。它于2014年5月8日被发现,一直折磨我们到现在,这一年多我们只能依靠“每天重启应用程序”过着云上的“幸福”生活。

(“黑色1秒”最显著的特征:QPS为0)

折磨我们到现在,我们也与之斗争到现在。虽然我们曾经信心满满地怀疑——黑色1秒,微软的问题还是阿里云的问题?,但我们依然没办法百分百确认与我们的应用程序无关,因为之前没有在阿云上发现遇到同样问题的第2位用户。用尽各种招式之后,我们只剩最后一招——借着.NET跨平台的东风,等.NET Core/ASP.NET 5推出后,将Web服务器由Windows换成Linux,来验证“黑色1秒”是否是应用程序有关。当然,这一招也是非常艰苦的一招,要大量修改应用程序的代码,要等跨平台.NET的推出,我们预计至少需要一年的时间。

同时,阿里云也一直与之斗争。开始投入很多力量优化Xen,“黑色1秒”依旧;接着把Xen换成KVM,“黑色1秒”还是依旧;后来推出带SSD临时磁盘的云服务器,“黑色1秒”继续依旧。。。

正当“黑色1秒”问题的解决没有一线希望,正当准备与“黑色1秒”打一场待久战时,开头说的2件神奇的事情降临了。

当得知第2位阿里云用户遇到了与我们一模一样的“黑色1秒”,我们就无需采用最后一招去验证了。这个问题已经不是我们可以解决或者可以帮助解决的,只能等阿里云去解决。

当得知阿里云推出了有望解决“黑色1秒”问题的新服务器,我们终于等到了一次来之不易的希望。立马部署新服务器进行验证。

昨天13:30左右,新服务器上线。根据之前的多次观察,“黑色1秒”在程序持续运行24小时后必然出现。

今天13:30之后,进行着紧张的观察。13:40没出现“黑色1秒”,13:50没出现“黑色1秒”,14:00也没出现“黑色1秒”。。。但我们还是不敢轻易确认“黑色1秒”问题已解决。因为曾经的一次一次希望落空记忆犹新。

一直观察到15:00,QPS一直很稳定,没有出现一次QPS为0的情况。

这时我们才敢相信这一次幸福真的来了——“黑色1秒”终于问题解决啦!云上真正的幸福生活开始啦!

时间: 2024-10-10 04:11:32

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

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

“幸福没有那么容易,才会特别让人着迷”,这是黄小琥的<没那么简单>中的一句歌词. 这句歌词或许最能表达我们此刻的心情——在我们宣布“黑色1秒”问题已解决的第二天,“黑色1秒”竟然再次出现! 昨天早上8点左右起床后,睡眼惺忪地查看服务器的实时监控,打算欣赏一下“黑色1秒”被消灭后那漂亮的QPS曲线.突然,一个即将被最新曲线覆盖的锯齿闪现在眼前——黑色1秒!不会吧?怎么会?这不是真的,或许是自己迷迷糊糊弄错了服务器,或许是自己余梦未醒?... 当时真的不敢相信,以为是自己什么地方弄错了.所以,继续

云计算之路-阿里云上:Wireshark抓包分析一个耗时20秒的请求

这篇博文分享的是我们针对一个耗时20秒的请求,用Wireshark进行抓包分析的过程. 请求的流程是这样的:客户端浏览器 -> SLB(负载均衡) -> ECS(云服务器) -> SLB -> 客户端浏览器. 下面是分析的过程: 1. 启动Wireshark,针对内网网卡进行抓包. 2. 在IIS日志中找出要分析的请求(借助Log Parser Studio) 通过c-ip(Client IP Address)可以获知SLB的内网IP,在分析Wireshar抓包时需要依据这个IP进

云计算之路-阿里云上:超过70秒的请求抓包分析

超过70秒的请求是通过分析IIS日志发现的: 10.159.63.104是SLB的内网IP. 通过Wireshark抓包分析请求是9:22:21收到的(tcp.stream eq 23080): 09:22:21.299838000 10.159.63.104 10.161.241.208 HTTP 291 GET /eastsea/p/3764040.html HTTP/1.0 这个请求响应内容的长度是:Content-Length 1154110(1.1MB) 云服务器(ECS)在收到请求后

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

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

云计算之路-阿里云上:CPU 100%引发的状况

今天下午17:00-17:05之间,在请求量没有明显变化的情况下,SLB中的1台云服务器的CPU突然串到100%(当时SLB中一共有3台云服务器),见下图: 造成的直接后果是请求执行时间变得超长,最长竟然达到了53秒(下图中的紫色线条). 另外伴随的表现是大量请求排队. 再看看这个时间段其它2台服务器的表现: 从这些现象分析,我们猜测CPU 100%这台云服务器出现了CPU资源争抢问题,将之从SLB中摘除后恢复正常. 云计算之路-阿里云上:CPU 100%引发的状况,布布扣,bubuko.com

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

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

云计算之路-阿里云上:消灭“黑色n秒”第一招——不让CPU空闲

昨天对"黑色n秒"问题的最终猜想以失败而告终,从而让我们结束了被动猜想阶段,进入了主动进攻阶段--出招. 今天出第一招--用C#写个小程序,让其在每个CPU核上运行一个线程,不让任何一个CPU核进入空闲(idle)状态,以进一步排除CPU idle引起的"黑色n秒". 在这一招中,借助的最重要的武器是System.Diagnostics.ProcessThread.ProcessorAffinity.通过给ProcessorAffinity设置一个掩码,就可以指定当

云计算之路-阿里云上:消灭“黑色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