云计算之路-阿里云上:神奇的“黑色30秒”再次出现,究竟是谁的错?
自从4月28日我们从ASP.NET线程的角度对“黑色30秒”问题进行分析之后,我们采用了新的线程设置,然后观察“黑色30秒”是否再次出现。
<processModel enable="true" requestQueueLimit="5000" maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50" minIoThreads="50"/>
采用以上设置之后,Requests Queued出现的频率的确少了。之后的几天,也没出现“黑色30秒”。
于是,ASP.NET线程设置问题引起“黑色30秒”的可能性已经提升到了99.9%,对阿里云的怀疑只剩下0.1%。
但是:
1. 上次的总结中提到“如果把'黑色30秒‘问题归因于ASP.NET线程问题,除了30秒左右的这个时间,其他问题表现都得到了更合理的解释。”,评论中也有朋友提到“不像是这个问题。为什么是30秒而不是20秒,或者50秒?”,这个最显著的特征却一直找不到合理的解释,让人无法划上圆满的句号。
2. 之前观察的阶段处于五一假期前夕,流量有所下降,没有出现真正的访问高峰,所以需要通过这周的访问高峰进行验证。当阿里云客服想结束工单时,我们说还需要这周的观察。
。。。
结果,今天下午神奇的“黑色30秒”再次降临,而这次“黑色30秒”期间没有出现Requests Queued,请看以下的Windows性能监视器的监视情况。
这次只看4个指标:Requests Executing,Processor Time,Request Execution Time,Current Connections。
1. Requests Executing如过山车
这是这次“黑色30秒”期间最最显著的表现。
2. CPU先抑后扬
3. Request Execution Time在玩蹦极
4. Current Connections有点像撑杆跳
5. 4个指标的叠加
从上面的表现来看,很明显,“黑色30秒”期间正在执行的请求卡住了,或者更准确地说正在执行请求的线程卡住了。
与之前的表现(如下图Requests Queued的上升)相比,这次似乎是新的情况。
根本不是!这只是同一个问题在不同条件下的表现——
之前由于线程设置的少,所以当当前处理请求的线程卡住后,后续的请求只能排队。
而这次当当前处理请求的线程卡住后,后续的请求过来时,ASP.NET可以有更多空闲线程处理这些请求,而在请求处理过程中这些线程也卡住了,所以表现为Requests Executing飙升。
现在我们猜测“黑色30秒”的触发条件是在高并发下线程突然卡住了。
为什么线程会卡住?为什么会是30秒?应用程序的原因,Windows的原因,还是阿里云的原因?大家可以投投票。
如果您对Xen有研究,期待您从dom0 CPU调度策略角度分析可能的原因。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· .NET Core 托管堆内存泄露/CPU异常的常见思路
· PostgreSQL 和 SQL Server 在统计信息维护中的关键差异
· C++代码改造为UTF-8编码问题的总结
· DeepSeek 解答了困扰我五年的技术问题
· 为什么说在企业级应用开发中,后端往往是效率杀手?
· 2分钟学会 DeepSeek API,竟然比官方更好用!
· .NET 使用 DeepSeek R1 开发智能 AI 客户端
· autohue.js:让你的图片和背景融为一体,绝了!
· 10亿数据,如何做迁移?
· 推荐几款开源且免费的 .NET MAUI 组件库
2010-05-05 博客园电子期刊2010年4月刊发布啦