文章編號: 821268 - 上次校閱: 2011年7月2日 - 版次: 13.0

爭用、 效能不佳、 和死結 (deadlock) 當您從 ASP 進行 Web 服務要求。NET 應用程式

中英文對照顯示按一下這裡顯示機器翻譯的中英文對照
機器翻譯檢視機器翻譯免責聲明
檢視此文章適用的產品。
系統提示本文適用於您使用的作業系統之外的作業系統。與您不相關的文章內容已停用。

在此頁中

全部展開 | 全部摺疊

徵狀

當您對進行 ASP 從 XML Web 服務呼叫。NET應用程式，您可能會發生爭用、 效能不佳、 和死結 (deadlock)。用戶端可能會報告要求停止回應 (或 「 擱置 」)，或採取非常長的時間來執行。如果懷疑死結，可能是背景工作處理序回收。您可能會收到下列訊息的應用程式事件記錄檔中。
  • 如果您使用 Microsoft Internet Information Services(IIS) 5.0 版，您會收到下列訊息中的應用程式事件記錄:

       Event Type:     Error
   Event Source:   ASP.NET 1.0.3705.0
   Event Category: None
   Event ID:       1003
   Date:           5/4/2003
   Time:           6:18:23 PM
   User:           N/A
   Computer:       <ComputerName>
   Description:
      aspnet_wp.exe  (PID: <xxx>) was recycled because it was suspected to be in a deadlocked state.
      It did not send any responses for pending requests in the last 180 seconds.

  • 如果您使用 IIS 6.0，您會收到下列應用程式事件記錄檔中的訊息：

       Event Type:     Warning
   Event Source:   W3SVC-WP
   Event Category: None
   Event ID:       2262
   Date:           5/4/2003
   Time:           1:02:33 PM
   User:           N/A
   Computer:       <ComputerName>
   Description:
      ISAPI 'C:\Windows\Microsoft.net\Framework\v.1.1.4322\aspnet_isapi.dll' reported itself as
      unhealthy for the following reason: 'Deadlock detected'.

  • 如果您使用 IIS 6.0，您會收到下列系統事件記錄檔中的訊息：

       Event Type:     Warning
   Event Source:   W3SVC
   Event Category: None
   Event ID:       1013
   Date:           5/4/2003
   Time:           1:03:47 PM
   User:           N/A
   Computer:       <ComputerName>
   Description:
      A process serving application pool 'DefaultAppPool' exceeded time limits during shut down.
      The process id was '<xxxx>'.

您也可能會收到下列的例外狀況錯誤訊息的時機您要撥接 HttpWebRequest.GetResponse 方法：
「 System.InvalidOperationException：若要完成的執行緒集區物件中沒有足夠可用的執行緒作業。"
您也可能會收到下列的例外狀況錯誤訊息在瀏覽器中：
「 HttpException (0x80004005)： 要求等待時間截止跨。"
附註 本文也適用於應用程式 HttpWebRequest 直接要求。
回此頁最上方

發生的原因

這個問題可能是因為 ASP。NET 會限制數目背景工作執行緒和完成通訊埠執行緒的呼叫可以用來執行要求。

一般來說，對 Web 服務的呼叫會使用一個背景工作執行緒執行會傳送要求和一個完成通訊埠執行緒的程式碼從 Web 服務接收回呼。不過，如果要求重新導向或需要驗證，請在呼叫可能會使用兩個背景工作和兩個完成通訊埠執行緒。因此，您可以耗盡受管理當多個 Web 服務呼叫發生在同一時間，執行緒集區。

為範例中，假設執行緒集區僅限於 10 個背景工作執行緒，以及所有10 個背景工作執行緒目前正在執行的程式碼，都在等待回呼若要執行。回呼可以永遠不會執行，因為任何工作項目排入執行緒集區會被封鎖，直到執行緒變成使用這個選項。

另一個潛在的競爭來源是 maxconnection 參數， System.Net 命名空間使用的連線數目限制。一般而言，此限制的運作如預期般運作。不過，如果許多應用程式嘗試進行許多在同一時間的單一 IP 位址的要求，執行緒可能必須等待可用的連線。
回此頁最上方

解決方案

若要解決這些問題，您可以調整下列最佳 Machine.config 檔案中的參數符合您的情況：
  • maxWorkerThreads
  • minWorkerThreads
  • maxIoThreads
  • minFreeThreads
  • minLocalRequestFreeThreads
  • maxconnection
  • executionTimeout
若要成功地解決這些問題，請執行下列作業：
  • 限制 ASP 的數目。NET 可以在執行的要求大約每個 CPU 的 12 至相同的時間。
  • 允許自由使用中的執行緒的 Web 服務回呼執行緒集區。
  • 選取適當的值 maxconnections 參數。您選取項目所依據的 IP 位址數目，所使用的 Appdomain。
附註 如果要限制的 ASP 建議事項。NET 要求 12每個 CPU 是任意的一點。不過，這項限制有良好的證明大部分的應用程式。
回此頁最上方

maxWorkerThreads 以及 maxIoThreads

ASP。NET 會使用下列兩個組態設定若要限制的背景工作執行緒與完成執行緒的數目上限使用： 
<processModel maxWorkerThreads="20" maxIoThreads="20">
[ maxWorkerThreads 參數和 maxIoThreads 參數會隱含地乘 Cpu 數目。為範例中，如果您有兩個處理器，背景工作執行緒的最大數目是下列步驟：
2 * maxWorkerThreads
回此頁最上方

minFreeThreads 以及 minLocalRequestFreeThreads

ASP。NET 也包含下列設定設定可決定多少的背景工作執行緒與完成通訊埠執行緒必須是可用於啟動遠端的要求或用於本機要求：
<httpRuntime minFreeThreads="8" minLocalRequestFreeThreads="8">
如果沒有足夠的執行緒可用，要求排入佇列直到足夠的執行緒可以執行要求。因此，ASP。NET 會不會執行下列的要求數目超過一次：
(maxWorkerThreads*Cpu 數目)-minFreeThreads
附註 [ minFreeThreads 參數和 minLocalRequestFreeThreads 參數會不隱含乘 Cpu 數目。
回此頁最上方

minWorkerThreads

作為的 ASP。NET 1.0 Service Pack 3 以及 ASP。NET 1.1 版中，ASP。NET 也包含下列組態設定，決定如何許多的背景工作執行緒可能會成為可立即處理遠端要求。 
<processModel minWorkerThreads="1">
執行緒由這所控制的多速度比建立設定從 CLR 的預設值 」 執行緒調整 」 所建立的背景工作執行緒功能。這項設定可以讓 ASP。NET 可能的服務要求突然填入 ASP。NET 要求佇列，因為在後端上 slow-down伺服器，要求從用戶端結束時，或類似的突然尖峰處理會導致在要求的數目突然上升時能夠在佇列中。[預設值 minWorkerThreads 參數設為 1。我們建議您設定的值 minWorkerThreads 為下列值的參數。 
minWorkerThreads = maxWorkerThreads / 2
預設情況下， minWorkerThreads 參數不是在 Web.config 檔案或Machine.config 檔中。這項設定隱含乘以數量Cpu。
回此頁最上方

maxconnection

[ maxconnection 參數會決定多少連線到特定的 IP 位址。參數如下所示：
<connectionManagement>
    <add address="*" maxconnection="2">
    <add address="65.53.32.230" maxconnection="12">
</connectionManagement>
討論稍早在這個參數設定發行項的處理序層級的所有項目。不過， maxconnection 參數設定會套用至應用程式網域層級。預設情況下，由於此設定會套用到應用程式網域層級，您可以建立最大值兩個連線至特定的 IP 位址，從每個應用程式網域中的程式處理程序。
回此頁最上方

executionTimeout

ASP。NET 會使用下列組態設定限制要求的執行時間: 
<httpRuntime executionTimeout="90"/>
您也可以使用，設定此限制 Server.ScriptTimeout 屬性。

附註 如果您增加的值 executionTimeout 參數，您可能也必須修改 processModelresponseDeadlockInterval 參數設定。
回此頁最上方

建議事項

建議您在本節中的設定也可能不適用於所有的應用程式。不過，下列的額外資訊可以協助您進行適當的調整。

如果當您建立一個 Web 服務呼叫單一 IP 位址從每一個 ASPX 頁面上，Microsoft 建議您使用下列組態設定：
  • 設定的值 maxWorkerThreads 參數和 maxIoThreads 參數 100.
  • 設定的值 maxconnection 參數 12 *N (其中 N 是 Cpu 數目，您有)。
  • 設定的值 minFreeThreads 參數 88 *N 以及 minLocalRequestFreeThreads 參數76 *N.
  • 設定值 minWorkerThreads 若要 50.請記住， minWorkerThreads 不是預設的組態檔中。您必須將它加入。
某些這些建議的牽涉到簡單的公式，包括數字伺服器上的 Cpu。代表中的 Cpu 數目的變數公式是 N.這些設定，如果您有啟用，超執行緒您必須使用邏輯 Cpu 數目而非實體 Cpu 數目。例如，如果您有四個處理器的伺服器與已啟用，然後超執行緒值 N 在公式中將會 8 而不是 4.

附註 當您使用此設定時，您可以執行最多 12 個ASP。NET 要求每個 CPU 同時因為 100 88 = 12.因此，至少 88 *N 背景工作執行緒和 88 *N 完成連接埠執行緒會可供其他使用 (例如 Web 服務回呼)。

例如，您必須具有四個處理器和超執行緒的伺服器已啟用。根據這些公式，您可以使用下列的值這份文件中所提及的組態設定。 
<system.web>
	<processModel maxWorkerThreads="100" maxIoThreads="100" minWorkerThreads="50"/>
	<httpRuntime minFreeThreads="704" minLocalRequestFreeThreads="608"/>
</system.web>

<system.net>
	<connectionManagement>
		<add address="[ProvideIPHere]" maxconnection="96"/>
	</connectionManagement>
</system.net>

此外，當您使用這項設定，12 連線就可以使用每個 CPU 每一個 IP 位址的每個應用程式網域。因此，在下列式子案例中，很少爭用發生於要求等待連接和執行緒集區是不會用完：
  • Web 裝載只有一個應用程式 (的應用程式網域)。
  • 每一個要求的 ASPX 頁面讓一個 Web 服務要求。
  • 所有要求都是相同的 IP 位址。
不過，當您使用此設定時，情節，涉及下列其中一項可能會使用太多連線：
  • 要求是以多個 IP 位址。
  • 要求會重新導向 (302 狀態碼)。
  • 要求需要驗證。
  • 從多個 Appdomain 發出要求。
在這些情況下，最好使用較低的值[ maxconnection 參數與較高的值 minFreeThreads 參數和 minLocalRequestFreeThreads 參數。
回此頁最上方

狀況說明

這行為是經過設計的。
回此頁最上方

其他相關資訊

如果您遇到效能不佳、 在 IIS 7.0 與 ASP 的爭用。Net 的詳細資訊，請參閱下列 Microsoft 部落格：

ASP。NET 執行緒使用方式，在 IIS 7.0 和 6.0
http://blogs.msdn.com/tmarq/archive/2007/07/21/asp-net-thread-usage-on-iis-7-0-and-6-0.aspx (http://blogs.msdn.com/tmarq/archive/2007/07/21/asp-net-thread-usage-on-iis-7-0-and-6-0.aspx)
在 IIS 7.0 中 ASP.net 擱置
http://blogs.msdn.com/webtopics/archive/2009/02/13/asp-net-hang-in-iis-7-0.aspx (http://blogs.msdn.com/webtopics/archive/2009/02/13/asp-net-hang-in-iis-7-0.aspx)
回此頁最上方

?考

如需詳細資訊，請造訪下列 Microsoft開發人員網路 (MSDN) 網站：
http://msdn2.microsoft.com/en-us/library/ms998549.aspx (http://msdn2.microsoft.com/en-us/library/ms998549.aspx)
回此頁最上方
這篇文章中的資訊適用於:
  • Microsoft .NET Framework 2.0
  • Microsoft ASP.NET 1.1
  • Microsoft ASP.NET 1.0
回此頁最上方
關鍵字：?
kbprb kbmt KB821268 KbMtzh
回此頁最上方
機器翻譯機器翻譯
重要：本文是以 Microsoft 機器翻譯軟體翻譯而成，而非使用人工翻譯而成。Microsoft 同時提供使用者人工翻譯及機器翻譯兩個版本的文章，讓使用者可以依其使用語言使用知識庫中的所有文章。但是，機器翻譯的文章可能不盡完美。這些文章中也可能出現拼字、語意或文法上的錯誤，就像外國人在使用本國語言時可能發生的錯誤。Microsoft 不為內容的翻譯錯誤或客戶對該內容的使用所產生的任何錯誤或損害負責。Microsoft也同時將不斷地就機器翻譯軟體進行更新。
按一下這裡查看此文章的英文版本：821268? (http://support.microsoft.com/kb/821268/en-us/ )
回此頁最上方
Microsoft及(或)其供應商不就任何在本伺服器上發表的文字資料及其相關圖表資訊的恰當性作任何承諾。所有文字資料及其相關圖表均以「現狀」供應，不負任何擔保責任。Microsoft及(或)其供應商謹此聲明，不負任何對與此資訊有關之擔保責任，包括關於適售性、適用於某一特定用途、權利或不侵權的明示或默示擔保責任。Microsoft及(或)其供應商無論如何不對因或與使用本伺服器上資訊或與資訊的實行有關而引起的契約、過失或其他侵權行為之訴訟中的特別的、間接的、衍生性的損害或任何因使用而喪失所導致的之損害、資料或利潤負任何責任。