婷婷综合国产,91蜜桃婷婷狠狠久久综合9色 ,九九九九九精品,国产综合av

主頁 > 知識庫 > 阿里云上從ASP.NET線程角度對“黑色30秒”問題的全新分析

阿里云上從ASP.NET線程角度對“黑色30秒”問題的全新分析

熱門標簽:云南外呼系統(tǒng)代理 上海市三維地圖標注 南昌自動外呼系統(tǒng)線路 西寧電銷外呼系統(tǒng)公司 辦公用地圖標注網點怎么操作 聊城智能電銷機器人電話 海東防封電銷卡 寧德防封版電銷卡 安陸市地圖標注app

在這篇博文中,我們拋開對阿里云的懷疑,完全從ASP.NET的角度進行分析,看能不能找到針對問題現象的更合理的解釋。

“黑色30秒”問題現象的主要特征是:排隊的請求(Requests Queued)突增,到達HTTP.SYS的請求數(Arrival Rate)下降,QPS(Requests/Sec)下降,CPU消耗下降,Current Connections上升。

昨天晚上18:08左右發(fā)生了1次“黑色30秒”,正好借此案例分析一下。

1、為什么Requests Queued會突增?

最直接的原因是ASP.NET沒有可用的線程處理當前請求。為什么會沒有可用的線程呢?ASP.NET可用的線程畢竟是有限的,可能是當時瞬間的并發(fā)請求太多,ASP.NET來不及創(chuàng)建足夠的線程處理這些請求。

我們來看一下ASP.NET中線程相關的設置——machine.config中的processModel(位于C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config)。

有4個相關設置:maxWorkerThreads(默認值是20), maxIoThreads(默認值是20), minWorkerThreads(默認值是1), minIoThreads(默認值是1)。(這些設置是針對每個CPU核)

我們用的就是默認設置,由于我們的Web服務器是8核的,于是實際的maxWorkerThreads是160,實際的maxIoThreads是160,實際的minWorkerThreads是8,實際的minIoThreads是8。

基于這樣的設置,是不是如果瞬間并發(fā)請求是169,就會出現排隊?不是的,ASP.NET沒這么傻!因為CLR 1秒只能創(chuàng)建2個線程,等線程用完時才創(chuàng)建,黃花菜都涼了。我們猜測ASP.NET只是根據這個設置去預測線程池中的可用線程是不是緊張,是不是需要創(chuàng)建新的線程,以及創(chuàng)建多少線程。

那什么情況下會出現“黑色30秒”期間那樣的大量請求排隊?假如并發(fā)請求數平時是300,突然某個瞬間并發(fā)請求數是600,超出了ASP.NET預估的所需的可用線程數,于是那些拿不到線程的請求只能排隊等待正在執(zhí)行的請求釋放線程以及CLR創(chuàng)建新的線程。隨著時間的推移,釋放出來的線程+新創(chuàng)建的線程足以處理這些排隊的請求,就恢復了正常。

那如何驗證這個猜測呢? 修改maxWorkerThreads, maxIoThreads, minWorkerThreads, minIoThreads的設置,讓ASP.NET提供更多的可用線程,目前我們采用的設置如下:

processModel enable="true" requestQueueLimit="5000" maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50" minIoThreads="50"/>

如果采用這個設置之后,“黑色30秒”現象幾乎不出現,就能驗證問題出在這個地方?,F在主站www.cnblogs.com已經使用了這個設置,需要觀察一段時間進行驗證。

【啟示】

1) 通過Windows性能監(jiān)視器監(jiān)視\ASP.NET\Requests Queued可以直觀地評估ASP.NET應用程序的吞吐能力(throughput)。

2) 通過ASP.NET異步編程(async/await)可以有效減少可用線程緊張造成的請求排隊問題。

2、為什么Arrival Rate會下降?

(上圖中的橙色線條)

這是“黑色30秒”問題中最讓人不解的地方,ASP.NET中請求再怎么排隊,怎么會造成到達HTTP.SYS的請求數下降呢?一開始我們總是不相信是請求排隊引起的Arrival Rate下降,但是監(jiān)視圖中卻鐵證如山。

寫這篇博客之前,我們突然想通了!之前忽略了一個地方——當你打這篇博文時,第1個請求是html頁面,如果這個請求得到正常響應,瀏覽器在加載這個頁面時會發(fā)出多個ajax請求;如果第1個請求被排隊,瀏覽器處于等待狀態(tài),后續(xù)的ajax請求就不會發(fā)出,這樣到達HTTP.SYS的請求數就會下降。這也解釋了為什么有時會在“黑色30秒”的中間階段Arrival Rate會飆高,正是因為當時被排隊的請求所對應的頁面中有很多ajax,當它結束排隊被執(zhí)行后,后續(xù)的很多ajax請求(可能排隊的很多是這樣的請求)到達了HTTP.SYS。

于是,我們相信了是請求排隊引起的Arrival Rate下降。

【啟示】

不能把目光局限于當前看到的問題表現,而要綜合考慮,將諸多因素聯系起來理清各種現象之間的關系。

3、QPS下降

與Arrival Rate下降同理,QPS(Requests/Sec)與Arrival Rate是直接相關的,成正比關系。

于是,QPS下降也是因為請求排隊。

4、CPU消耗下降

也是同理,Arrival Rate與QPS下降,說明CPU要干的活少了,自然消耗就下降。

于是,CPU消耗下降也是因為請求排隊。

5、Current Connections上升

Current Connections是請求排隊的一個直接表現,請求還沒被執(zhí)行,連接當然會保持著。

于是,Current Connection上升也是因為請求排隊。

6、看一個新指標Requests Executing

(上圖綠色的線條表示的是Requests Executing)

在請求排隊的期間,正在被ASP.NET執(zhí)行的請求數(Requests Executing)在增加,說明隨著被釋放出來的線程增多以及更多的新線程被創(chuàng)建,排列中的請求正在被越來越多地執(zhí)行。這從側面說明了執(zhí)行中的線程可能是正常的,沒有被卡住。(接下來的IIS日志信息會進一步驗證這一點)

于是,Requests Executing在增加也是因為請求被排隊,而且說明這個排隊是正常的,沒有哪個地方卡住了。

7、再來看看IIS日志中請求的time-taken

在“黑色30秒”階段,IIS日志中沒有time-taken超過1s的請求!這說明了什么?說明了正在被執(zhí)行的請求處理速度很快,沒有什么地方被卡住。。。除了因為可用線程不夠,請求被排隊。

于是,IIS日志說明除了請求排隊,其他地方一切正常。

【總結】

如果把“黑色30秒”問題歸因于ASP.NET線程問題,除了30秒左右的這個時間,其他問題表現都得到了更合理的解釋。

寫這篇博客之前,我們當時覺得ASP.NET線程問題引起“黑色30秒”問題的可能性是80%,寫完這7點分析之后,我們覺得可能性是99%,除非這次分析的“黑色30秒”與之前的“黑色30秒”不是同一個問題。

現在還需要我們使用新設置(maxWorkerThreads="100", maxIoThreads="100", minWorkerThreads="50", minIoThreads="50")之后的驗證。

大結局即將來臨,重要的可能不是結局是什么,而是其中的過程,我們分享的也是解決問題的過程。

標簽:汕尾 南寧 平涼 衢州 贛州 青海 洛陽 崇左

巨人網絡通訊聲明:本文標題《阿里云上從ASP.NET線程角度對“黑色30秒”問題的全新分析》,本文關鍵詞  阿里,云,上,從,ASP.NET,線程,;如發(fā)現本文內容存在版權問題,煩請?zhí)峁┫嚓P信息告之我們,我們將及時溝通與處理。本站內容系統(tǒng)采集于網絡,涉及言論、版權與本站無關。
  • 相關文章
  • 下面列出與本文章《阿里云上從ASP.NET線程角度對“黑色30秒”問題的全新分析》相關的同類信息!
  • 本頁收集關于阿里云上從ASP.NET線程角度對“黑色30秒”問題的全新分析的相關信息資訊供網民參考!
  • 推薦文章
    主站蜘蛛池模板: 咸阳市| 肥西县| 新津县| 尚志市| 萍乡市| 邓州市| 镇江市| 云龙县| 石柱| 六安市| 遂川县| 铅山县| 伊金霍洛旗| 灵宝市| 宜黄县| 莎车县| 洛川县| 陈巴尔虎旗| 筠连县| 常州市| 合江县| 新竹市| 洪湖市| 九龙坡区| 靖远县| 晋江市| 沧州市| 长春市| 鄂托克旗| 宜州市| 南溪县| 松原市| 高平市| 三门县| 资中县| 大名县| 济源市| 同仁县| 区。| 崇左市| 民和|