云计算之路-阿里云上:对“黑色30秒”问题的猜想
2014-04-24 12:01
232 查看
在云上,底层的东西你无法触及,遇到奇怪问题时只能靠猜想,所以使用云计算会锻炼你的想像力。
(上图中蓝色是ASP.NET的Requests Queued,另外一个是HTTP.SYS的Arrival Rate)
昨天我们发现了一个重要的线索——“黑色30秒”到来时,最初的表现是请求出现排队(Requests Queued上升),到达IIS的请求数量(Arrival Rate)下降。
而问题奇特之处就在Arrival Rate下降。如果只是Requests Queued上升,而Arrival Rate处于正常水平,我们首先会怀疑应用程序的原因——应用程序在处理请求时卡在哪个地方;而Requests Queued上升伴随着Arrival Rate下降,说明不仅后面出不去(请求完成不了),而且前面进不来(请求到达不了IIS)。应用程序不管出什么样的问题,都不可能造成Arrival Rate下降,所以我们目前找不到任何理由去怀疑应用程序。
于是,我们针对“前面请求进不来,后面请求出不去”展开了风花雪月的想像,终于找到了一个看上去说得通的猜想,下面分享一下。
*先看一下用户的请求是如何到达Web服务器的?
用户浏览器 -> SLB(阿里云负载均衡) -> VM(虚拟机)-> Web服务器
*再看Web服务器如何将响应发送给用户的?
Web服务器 -> VM -> SLB -> 用户浏览器
【猜想 】
假设SLB或VM在某种触发条件下,偷偷地断掉了一些TCP连接,并且不向用户端与服务端发送 FIN 或者 RST 报文,除了肇事者,谁也不知道。于是:
1) 用户端不知道TCP连接被断,还继续用这个TCP连接发包,结果请求当然到不了Web服务器,造成Arrival Rate下降。用户端TCP层发包后,等回包(比如ACK包),迟迟等不到,一直等到超时(假设超时时间是30s),才知道TCP链路挂掉了;然后重建TCP连接重发请求,这时请求成功到达了Web服务器,当前的请求+之前被断连接的请求一起到达Web服务器,这正好解释了“黑色30秒”结束阶段Arrival Rate会突增到一个高点。
2)Web服务器端与SLB端(或者SLB端与用户端)的TCP连接被断,Web服务器不知道,在处理完请求后还继续用这个断掉的TCP连接发送响应包并等回包,迟迟等不到,造成请求处理不能完成而被堆积,从而进一步造成后续的请求没有足够的资源可用而排队,于是Requests Queued上升;一直等到超时(假设超时时间是30s),Web服务器才知道TCP链路挂掉了,然后放弃这些请求处理,于是有了足够的资源处理队列中的请求,这正好解释了“黑色30秒”结束阶段Requests Queued会突降。
这就是我们目前找到的唯一能解释得通“黑色30秒”问题表现的一个猜想。
(上图中蓝色是ASP.NET的Requests Queued,另外一个是HTTP.SYS的Arrival Rate)
昨天我们发现了一个重要的线索——“黑色30秒”到来时,最初的表现是请求出现排队(Requests Queued上升),到达IIS的请求数量(Arrival Rate)下降。
而问题奇特之处就在Arrival Rate下降。如果只是Requests Queued上升,而Arrival Rate处于正常水平,我们首先会怀疑应用程序的原因——应用程序在处理请求时卡在哪个地方;而Requests Queued上升伴随着Arrival Rate下降,说明不仅后面出不去(请求完成不了),而且前面进不来(请求到达不了IIS)。应用程序不管出什么样的问题,都不可能造成Arrival Rate下降,所以我们目前找不到任何理由去怀疑应用程序。
于是,我们针对“前面请求进不来,后面请求出不去”展开了风花雪月的想像,终于找到了一个看上去说得通的猜想,下面分享一下。
*先看一下用户的请求是如何到达Web服务器的?
用户浏览器 -> SLB(阿里云负载均衡) -> VM(虚拟机)-> Web服务器
*再看Web服务器如何将响应发送给用户的?
Web服务器 -> VM -> SLB -> 用户浏览器
【猜想 】
假设SLB或VM在某种触发条件下,偷偷地断掉了一些TCP连接,并且不向用户端与服务端发送 FIN 或者 RST 报文,除了肇事者,谁也不知道。于是:
1) 用户端不知道TCP连接被断,还继续用这个TCP连接发包,结果请求当然到不了Web服务器,造成Arrival Rate下降。用户端TCP层发包后,等回包(比如ACK包),迟迟等不到,一直等到超时(假设超时时间是30s),才知道TCP链路挂掉了;然后重建TCP连接重发请求,这时请求成功到达了Web服务器,当前的请求+之前被断连接的请求一起到达Web服务器,这正好解释了“黑色30秒”结束阶段Arrival Rate会突增到一个高点。
2)Web服务器端与SLB端(或者SLB端与用户端)的TCP连接被断,Web服务器不知道,在处理完请求后还继续用这个断掉的TCP连接发送响应包并等回包,迟迟等不到,造成请求处理不能完成而被堆积,从而进一步造成后续的请求没有足够的资源可用而排队,于是Requests Queued上升;一直等到超时(假设超时时间是30s),Web服务器才知道TCP链路挂掉了,然后放弃这些请求处理,于是有了足够的资源处理队列中的请求,这正好解释了“黑色30秒”结束阶段Requests Queued会突降。
这就是我们目前找到的唯一能解释得通“黑色30秒”问题表现的一个猜想。
相关文章推荐
- 云计算之路-阿里云上:排查“黑色30秒”问题-为什么请求会排队
- 云计算之路-阿里云上:对“黑色n秒”问题的最终猜想——CPU C-states引起的
- 云计算之路-阿里云上:Web服务器遭遇奇怪的“黑色30秒”问题
- 云计算之路-阿里云上:借助IIS Log Parser Studio分析“黑色30秒”问题
- 阿里云上从ASP.NET线程角度对“黑色30秒”问题的全新分析
- 云计算之路-阿里云上:神奇的“黑色30秒”再次出现,究竟是谁的错?
- 云计算之路-阿里云上:“黑色30秒”走了,“黑色1秒”来了,真相也许大白了
- 云计算之路-阿里云上:黑色1秒,微软的问题还是阿里云的问题?
- 云计算之路-阿里云上:对“黑色n秒”问题的最终猜想——CPU C-states引起的
- 云计算之路-阿里云上:从ASP.NET线程角度对“黑色30秒”问题的全新分析
- 云计算之路-阿里云上:“黑色1秒”问题与2009年Xen一个补丁的故事
- 云计算之路-入阿里云后:对云服务器并发连接问题的猜想
- 云计算之路-阿里云上:结合IIS日志分析“黑色30秒”问题
- 阿里云上从ASP.NET线程角度对“黑色30秒”问题的全新分析
- 云计算之路-阿里云上-幸福总是很突然:“黑色1秒”问题解决啦
- 云计算之路-阿里云上:奇怪的CPU 100%问题
- 云计算之路-阿里云上:原来“黑色0.1秒”发生在socket读取数据时
- 云计算之路-阿里云上:基于Xen的IO模型进一步分析“黑色0.1秒”问题
- 云计算之路-阿里云上:消灭“黑色n秒”第三招——禁用网卡的TCP/IP Offload
- 云计算之路-阿里云上:什么是“黑色1秒”?