Asp.net應用程序運行緩慢，但CPU最多爲40％

Question

我在生產服務器上出現了一種奇怪的情況。 asp.net連接排隊，但CPU只有40％。此外，數據庫在30％的CPU上運行良好。

如意見要求一些更多的歷史：

• 在高峯時段的網站得到一個小時左右的兩萬人次。
• 該網站是一個asp.net web表單應用程序有很多AJAX /職位的
• 該網站使用產生了大量用戶的內容
• 我們測量站點的性能與不打的數據庫和testpage該網站使用的網絡服務。在正常負載下，此頁面在一秒內得到處理。當請求花費超過4秒鐘時，將應用程序定義爲緩慢。
• 從測量結果我們可以看出連接時間很快，但處理時間很長。
• 我們無法確定單個請求的緩慢響應，網站在正常時段運行良好，但在高峯時段速度較慢
• 我們遇到了一個問題，即該網站受CPU限制（又名100％運行），我們修復
• 我們也遇到了例外問題，我們修復了這個問題
• 在高峯時段我會看看asp.net性能計數器。我們可以看到我們有500個當前連接和500個排隊連接的行爲。
• 在高峯時期的CPU爲40％左右（這讓我覺得它不是CPU綁定）
• 物理內存大約是使用60％
• 在高峯時期的DATABASESERVER CPU在30％左右（其中讓我覺得它不是數據庫綁定）

我的結論是，別的東西是阻止服務器更快地處理請求。可能的犯罪嫌疑人

• 死鎖（syncblk只給出了一個鎖！）
• 磁盤I/O（通過Sysinternals的procesexplorer檢查：3.5 MB /秒）
• 垃圾收集（10〜15峯期間％）
• 網絡I/O（連接時間仍然很短）

要了解我在創建小型轉儲程序時所做的操作。

我設法創建了兩個相隔20秒的MemoryDump。這是第一個輸出：

!threadpool 
CPU utilization 6% 
Worker Thread: Total: 95 Running: 72 Idle: 23 MaxLimit: 200 MinLimit: 100 
Work Request in Queue: 1 
-------------------------------------- 
Number of Timers: 64 

和第二輸出：

!threadpool 
CPU utilization 9% 
Worker Thread: Total: 111 Running: 111 Idle: 0 MaxLimit: 200 MinLimit: 100 
Work Request in Queue: 1589 

正如你可以看到有很多隊列請求的。

問題1：這是什麼意思，在隊列中有1589個請求。這是否意味着阻礙了某些東西？！

線程池清單主要包含以下項目： 未知函數：6a2aa293語境：01cd1558 AsyncTimerCallbackCompletion TimerInfo @ 023a2cb0

如果我你與AsyncTimerCallbackCompletion

!dumpheap -type TimerCallback 

然後深入我看看TimerCallback中的對象和大多數類型：

System.Web.SessionState.SessionStateModule 
System.Web.Caching.CacheCommon 

問題2：這些對象有一個計時器，這麼有意義嗎？我應該防止這一點。如何？

主要問題我錯過任何明顯的問題，爲什麼我排隊連接，並沒有最大限度的CPU？

---

我成功地在高峯期做出了故障轉儲。用debugdiag分析它給了我這個警告：

Detected possible blocking or leaked critical section at webengine!g_AppDomainLock owned by thread 65 in Hang Dump.dmp 
Impact of this lock 
25.00% of threads blocked 
(Threads 11 20 29 30 31 32 33 39 40 41 42 74 75 76 77 78 79 80 81 82 83) 

The following functions are trying to enter this critical section 
webengine!GetAppDomain+c9 

The following module(s) are involved with this critical section 
\\?\C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\webengine.dll from Microsoft Corporation 

快速谷歌搜索不給我任何結果。有人有線索嗎？

Answer 1

處理隊列的工作進程是真正的破壞者。可能與在同一主機上調用Web服務的網站連接。從而造成了一種僵局。

我改變了machine.config中對以下內容：

<processModel 
     autoConfig="false" 
     maxWorkerThreads="100" 
     maxIoThreads="100" 
     minWorkerThreads="50" 
     minIoThreads="50" /> 

標準中processModel這個設置爲自動配置=「真」

隨着新的配置Web服務器正在處理請求的速度不夠快，不排隊。

Answer 2

太多的ASP.NET排隊請求會破壞性能。請求線程數量非常有限。

嘗試通過異步處理頁面緩慢部分來釋放這些線程，或者執行任何其他操作來減少頁面執行時間。

Answer 3

我與realworldcoder：IIS工作通過讓工作進程處理傳入的請求。如果請求疊加起來，看起來正在發生，那麼性能會大幅下降。

有幾種可能的事情要做/檢查。

1. 啓動SQL Server上的活動監視器。您想查看哪些查詢花費的時間最長，並根據結果進行更改以減少執行時間。長查詢可能會導致頁面正在執行的線程阻塞，從而減少您可以支持的連接數量。

2. 查看這些頁面/ ajax調用的查詢數量和執行時間。我已經看到了幾十個不必要的查詢的頁面，這些查詢被執行了一個Ajax調用，因爲.Net執行整個頁面循環，即使只有一個特定的方法需要運行。您可以將這些調用分成常規Web處理程序（.ashx）頁面，這樣可以更好地控制發生的情況。

3. 考慮增加IIS必須處理傳入請求的工作進程數。新應用程序池的默認值是20 threads的1個進程。這通常足以處理大量的請求;但是，如果由於等待數據庫服務器或某些其他資源而導致請求阻塞，則可能導致管道堆疊。請記住，這可能會對應用程序的性能和正常運行產生積極或消極的影響。所以做一些研究然後測試，測試和測試。

4. 考慮減少或消除您對會話的使用。無論哪種方式，看看它的內存使用情況，可能會增加更多內存到您的Web服務器。無論數據是否被使用，會話數據都會被序列化並反序列化以用於每個頁面加載（包括ajax調用）。取決於您在會話中存儲的內容，它可能會對您的網站產生嚴重的負面影響。如果你沒有使用它，那麼確保它完全在你的web.config中關閉。請注意，如果將會話存儲在Web服務器上，則這些問題只會變得更糟，因爲當頁面檢索並存儲時，您將受到網絡速度的約束。

5. 查看圍繞JIT（Just-In-Time）編譯的站點性能計數器。這應該幾乎不存在。我見過大量的JIT讓他們跪在地上。一旦這些網頁被重新編碼以消除它，網站又開始飛行。

6. 看看不同的緩存策略（我不認爲會話是一個真正的緩存解決方案）。也許有些事情你不斷要求你不需要經常退出數據庫服務器。我的一個朋友有一個網站，他們將整個網頁緩存爲動態內容的物理文件，包括他們的討論組。這大大提高了他們的表現;但這是一個重大的體系結構變化。

以上只是一些需要注意的事情。你基本上需要進一步深入細節，找出究竟發生了什麼，大多數常規性能計數器都不會給你那麼明確。

Answer 4

有人能證實這對他們有效嗎？我在網上發現了這個答案，並且沒有確認發佈的答案爲他們解決了這個問題。據說，由於問題海報提供了答案，所以我沒有真正給出它的可信度。

我最近同樣的問題：在 w3wp.exe__DefaultAppPool__PID__3920__Date__04_26_2011__Time_10_40_42AM__109__IIS_COM由線程16擁有

檢測到可能的阻塞或泄漏的關鍵部分在 webengine g_AppDomainLock + 杭Dump.dmp 這把鎖的影響

4.17％的主題被屏蔽 （主題17） 以下功能正試圖進入這個關鍵部分web引擎！GetAppDoma in + c9 以下模塊涉及此關鍵部分\？\ c：\ WINDOWS \ microsoft.net \ framework \ v2.0.50727 \ webengine。從 微軟公司dll的

這是由微軟發佈，以進一步解決的建議：

以下供應商，確定了後續基於根 原因分析微軟公司 請與跟進供應商確定上述。請看下面的方法來確定這個關鍵部分 問題根源：

1. 啓用應用程序驗證 A.下載應用程序驗證從以下網址「鎖定檢查」：http://www.microsoft.com/downloads/en/details.aspx?FamilyID=c4a25ab9-649d-4a1b-b4a7-c9d8b095df18&displaylang=en B.啓用「鎖定檢查」通過運行下面的命令此過程：

   Appverif.exe -enable locks -for w3wp.exe C.參見以下文獻的更多信息，應用程序驗證： http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnappcom/html/appverifier.asp?frame=true

2. 使用DebugDiag資料崩潰規則監視異常

Answer 5

我知道這是一個古老的線程，但它是第一個谷歌打了人ASP.NET網站表現不佳的一個應用。所以我會拋出一些建議：

1）異步編程將解決根本原因。當你打電話給web服務來完成你的實際業務邏輯時，那些請求線程只是坐在那裏等待響應。它們可以用來代替另一個傳入的請求。如果不能完全消除，這將大大減少隊列長度。異步編程是關於可伸縮性的，而不是個別的請求性能。在.NET 4.5中使用Async/Await模式很容易實現。 ASP.NET以每分鐘2次的速度注入線程，因此除非您重新使用這些現有的線程，否則您將很快耗盡您收到的網站負載。此外，旋轉更多的線程是一個小的性能問題。它佔用更多的RAM和時間來分配RAM。只是增加machine.config中的線程池大小並不能解決潛在的問題。除非添加更多的CPU，否則添加更多線程並不會真正起到幫助作用，因爲它仍然是資源的錯誤分配，並且您也可以通過擁有太多線程和CPU太少來將自己切換到死亡狀態。

2）From a popular article on threading in IIS 7.5：如果您的ASP.NET應用程序使用Web服務（WFC或ASMX）或System.Net與HTTP通過後端進行通信，則可能需要增加connectionManagement/maxconnection。對於ASP.NET應用程序，autoConfig功能限制爲12 * #CPU。這意味着在一個四端口處理器上，最多可以有12 * 4 = 48個併發連接到IP端點。因爲這與autoConfig綁定，所以在ASP.NET應用程序中增加maxconnection的最簡單方法是例如從Application_Start以編程方式設置System.Net.ServicePointManager.DefaultConnectionLimit。將該值設置爲您希望應用程序使用的併發System.Net連接數。我已經將它設置爲Int32.MaxValue，並且沒有任何副作用，所以你可以嘗試一下 - 這實際上是在本地HTTP堆棧WinHTTP中使用的默認值。如果您無法以編程方式設置System.Net.ServicePointManager.DefaultConnectionLimit，則需要禁用autoConfig，但這意味着您還需要設置maxWorkerThreads和maxIoThreads。如果您不使用傳統/ ISAPI模式，則不需要設置minFreeThreads或minLocalRequestFreeThreads。

3）如果你每小時獲得20K獨立訪問者，你應該仔細考慮負載均衡。如果每個用戶每小時都做10-20個AJAX請求，那麼您很容易就會向您的後端談論大約100萬次或更多的Web服務調用。拋出另一臺服務器將減少主服務器上的負載。將它與async/await結合起來，你已經把自己置於一個很好的情況下，在這個情況下你可以很容易地拋出硬件來解決問題（縮小）。這裏有多種好處，例如硬件冗餘，地理位置和性能。如果您使用的是AWS或RackSpace等雲提供商，則使用您的應用程序啓動另一個虛擬機很容易，可以通過手機完成。現在雲計算太便宜了，甚至有一個隊列長度。即使在切換到異步編程模型之前，您也可以這樣做來提供性能優勢。

4）擴展：向服務器添加更多硬件會有所幫助，因爲當您擁有更多線程時，它可以提供更好的穩定性。更多的線程意味着你需要更多的CPU和RAM。即使您已經在異步/等待下，您仍然希望儘可能調整這些Web服務請求。這可能意味着添加緩存層或增強數據庫系統。您不希望最大化該單臺服務器上的CPU。一旦CPU達到80％，ASP.NET將停止向系統注入更多線程。如果工作進程佔用0％，如果任務管理器報告的整個系統CPU利用率達到80％，則線程注入停止並且請求開始排隊，這並不重要。當垃圾收集檢測到服務器上的CPU負載過高時，也會發生奇怪的事情。