云计算之路-阿里云上:对“黑色30秒”问题的猜想

在云上,底层的东西你无法触及,遇到奇怪问题时只能靠猜想,所以使用云计算会锻炼你的想像力。

黑色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秒”问题表现的一个猜想。

posted @   博客园团队  阅读(3264)  评论(12编辑  收藏  举报
编辑推荐:
· .NET Core 托管堆内存泄露/CPU异常的常见思路
· PostgreSQL 和 SQL Server 在统计信息维护中的关键差异
· C++代码改造为UTF-8编码问题的总结
· DeepSeek 解答了困扰我五年的技术问题
· 为什么说在企业级应用开发中,后端往往是效率杀手?
阅读排行:
· 2分钟学会 DeepSeek API,竟然比官方更好用!
· .NET 使用 DeepSeek R1 开发智能 AI 客户端
· autohue.js:让你的图片和背景融为一体,绝了!
· 10亿数据,如何做迁移?
· 推荐几款开源且免费的 .NET MAUI 组件库
历史上的今天:
2013-04-24 云计算之路-黎明前的黑暗:20130424网站故障经过
点击右上角即可分享
微信分享提示