云计算之路-阿里云上:神奇的“黑色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如过山车

Requests Executing

这是这次“黑色30秒”期间最最显著的表现。

2. CPU先抑后扬

Processor Time

3. Request Execution Time在玩蹦极

Request Execution Time

4. Current Connections有点像撑杆跳

Current Connections

5. 4个指标的叠加

从上面的表现来看,很明显,“黑色30秒”期间正在执行的请求卡住了,或者更准确地说正在执行请求的线程卡住了。

与之前的表现(如下图Requests Queued的上升)相比,这次似乎是新的情况。

Requests Queued

根本不是!这只是同一个问题在不同条件下的表现——

之前由于线程设置的少,所以当当前处理请求的线程卡住后,后续的请求只能排队。

而这次当当前处理请求的线程卡住后,后续的请求过来时,ASP.NET可以有更多空闲线程处理这些请求,而在请求处理过程中这些线程也卡住了,所以表现为Requests Executing飙升。

现在我们猜测“黑色30秒”的触发条件是在高并发下线程突然卡住了。

为什么线程会卡住?为什么会是30秒?应用程序的原因,Windows的原因,还是阿里云的原因?大家可以投投票。

如果您对Xen有研究,期待您从dom0 CPU调度策略角度分析可能的原因。

posted @ 2014-05-05 19:41  博客园团队  阅读(5002)  评论(32编辑  收藏  举报