雲計算之路-阿裏雲上:排查“黑色30秒”問題-為什麽請求會排隊
http://www.cnblogs.com/cmt/p/3682642.html
針對Web服務器“黑色30秒”問題(詳見雲計算之路-阿裏雲上:Web服務器遭遇奇怪的“黑色30秒”問題),經過分析,我們準備從這個地方下手——為什麽會出現\ASP.NET\Request Queued大於0的情況(為什麽請求會排隊)?
首先, 通過Windows性能監視器去觀察,看能不能找到這樣的線索——在什麽條件下會觸發請求排隊?
我們在性能監視器中增加了1個監視指標——\HTTP Service Request Queues\Arrival Rate
Arrival Rate: Rate at which requests are arriving in the queue
這是一個針對IIS的底層HTTP.SYS的監視指標,從我們的理解,認為它最直接地反映了到達IIS的當前要處理的並發請求。
啟用這個Arrival Rate監視指標後,我們觀察到了1次請求排隊的情況(非“黑色30秒”故障場景)。
上圖中跳起的藍色就表現出現了請求排隊。
我們來逐個指標看一下。
1. HTTP Service Request Queues\Arrival Rate(到達IIS底層的請求)
當時HTTP.SYS收到了465個並發請求。
2. Qequests/Sec(QPS,ASP.NET每秒處理的請求數)
當時ASP.NET的QPS是607。
3. Requests Queued(排隊的請求數)
【註意】出現請求排隊的時間點是11:03:54,而前2個指標高上去的時間點在11:03:55。
【重要線索】由此,我們可以得出這樣的線索:是先出現請求排隊(Requests Queued),然後才出現Arrival Rate與QPS上升。是請求排隊引起Arrival Rate與QPS上升,而不是Arrival Rate與QPS上升引起請求排隊。
接下來通過其他指標驗證這個想法。
4. Current Connections
IIS當前連接數高上去也在出現請求排隊之後。(成功驗證1)
5. CPU
CPU占用也是在出現請求排隊之後才高上去的。(成功驗證2)
【分析結論】請求排隊才是問題的原因,而其他表現只是請求排隊後的結果表現。
那在11:03:54,請求排隊時,其他指標又是什麽情況呢?
1. ArrivalRate只有218
2. QPS只有151
3. Current Connections在15以下(具體數值在性能監視器上顯示不出來)
4. CPU占用只有10%
太奇怪了!在請求排隊時,其他指標都處於低點——比正常情況更低的點。
更奇怪的是到達IIS的請求比平時變少了,請求反而排隊了。
【猜想】
從這個監視到的表現看,我們唯一能解釋得通的是:11:03:54,Web服務器似乎在打瞌睡,處理能力全面下降;然後,11:03:55,Web服務器醒了過來,處理能力全面恢復,這時不僅要處理當前的請求,還要處理之前排隊的請求,一下子負載就高了上去。
難道誰給Web服務器下了藥?如果用的是物理機,我們真的會懷疑是誰下的藥?但現在用的是虛擬機,在“被下藥”與“虛擬機問題”之間,哪個更值得懷疑呢?。。。這個問題只能留給阿裏雲的同學,我們再怎麽懷疑,也只能懷疑而已,無法在虛擬機層面進行驗證。
【進一步的線索】
在寫這篇博客的期間,1臺服務器正好發生了“黑色30秒”,看看性能監視器中的相關表現:
1. Arrival Rate與Requests Queued
2. 加上Current Connections
3. 加上CPU
4. 加上Request Execution Time
而且這次接連來了2個“黑色30秒”。
【小結】
虛擬的世界很精彩,虛擬的世界也很無奈。從應用、從Windows的角度,我們真的不知從何處理下手,我們能做的只是找問題的線索。問題的解決可能真的需要阿裏雲同學們的努力!
雲計算之路-阿裏雲上:排查“黑色30秒”問題-為什麽請求會排隊