云计算之路-阿里云上:神奇的“黑色30秒”再次出现,究竟是谁的错?
2014-05-05 21:08
288 查看
自从4月28日我们从ASP.NET线程的角度对“黑色30秒”问题进行分析之后,我们采用了新的线程设置,然后观察“黑色30秒”是否再次出现。
采用以上设置之后,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有点像撑杆跳
从上面的表现来看,很明显,“黑色30秒”期间正在执行的请求卡住了,或者更准确地说正在执行请求的线程卡住了。
与之前的表现(如下图Requests Queued的上升)相比,这次似乎是新的情况。
根本不是!这只是同一个问题在不同条件下的表现——
之前由于线程设置的少,所以当当前处理请求的线程卡住后,后续的请求只能排队。
而这次当当前处理请求的线程卡住后,后续的请求过来时,ASP.NET可以有更多空闲线程处理这些请求,而在请求处理过程中这些线程也卡住了,所以表现为Requests Executing飙升。
现在我们猜测“黑色30秒”的触发条件是在高并发下线程突然卡住了。
为什么线程会卡住?为什么会是30秒?应用程序的原因,Windows的原因,还是阿里云的原因?大家可以投投票。
如果您对Xen有研究,期待您从dom0 CPU调度策略角度分析可能的原因。
<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有点像撑杆跳
从上面的表现来看,很明显,“黑色30秒”期间正在执行的请求卡住了,或者更准确地说正在执行请求的线程卡住了。
与之前的表现(如下图Requests Queued的上升)相比,这次似乎是新的情况。
根本不是!这只是同一个问题在不同条件下的表现——
之前由于线程设置的少,所以当当前处理请求的线程卡住后,后续的请求只能排队。
而这次当当前处理请求的线程卡住后,后续的请求过来时,ASP.NET可以有更多空闲线程处理这些请求,而在请求处理过程中这些线程也卡住了,所以表现为Requests Executing飙升。
现在我们猜测“黑色30秒”的触发条件是在高并发下线程突然卡住了。
为什么线程会卡住?为什么会是30秒?应用程序的原因,Windows的原因,还是阿里云的原因?大家可以投投票。
如果您对Xen有研究,期待您从dom0 CPU调度策略角度分析可能的原因。
相关文章推荐
- 云计算之路-阿里云上:神奇的“黑色30秒”再次出现,究竟是谁的错?
- 云计算之路-阿里云上:从ASP.NET线程角度对“黑色30秒”问题的全新分析
- 云计算之路-阿里云上:结合IIS日志分析“黑色30秒”问题
- 云计算之路-阿里云上:Linux内核bug引起的“黑色10秒钟”
- 云计算之路-阿里云上:对“黑色n秒”问题的最终猜想——CPU C-states引起的
- 云计算之路-阿里云上:“黑色10秒钟”的新进展
- 云计算之路-阿里云上-幸福没那么容易:“黑色1秒”又出现了
- 云计算之路-阿里云上:读取缓存时的“黑色0.1秒”
- 云计算之路-阿里云上:消灭“黑色n秒”第一招——不让CPU空闲
- 云计算之路-阿里云上:基于Xen的IO模型进一步分析“黑色0.1秒”问题
- 云计算之路-阿里云上:启用Windows虚拟内存引发的CPU 100%故障
- 云计算之路-阿里云上:3月5日下午出现的异常情况
- 云计算之路-阿里云上-阵雨:RDS故障的突袭
- 云计算之路-阿里云上:地域与可用区
- 云计算之路-阿里云:试用阿里云RDS——10分钟 vs 1小时16分钟
- 云计算之路-阿里云上-新车限行:新购服务器无法访问任何远程25端口
- 云计算之路-阿里云上-新车限行:新购服务器无法访问任何远程25端口
- 云计算之路-阿里云上:网站故障致歉
- 云计算之路-阿里云上:攻击的受害者,阿里云的罪人