是什么導致 IIS 中的應用程序池循環使用？

Question

我一直在搜索這方面的信息，但無濟於事。 我為什么需要這個的背景是我在這里問的另一個問題。 更具體地說，在 App_Data 中創建/更新/刪除文件會導致池回收嗎？

如果有人可以提供導致回收的原因的詳細列表，那就太好了。

更新：正如兩個用戶已經注意到的那樣，我也很樂意回答指定僅回收 AppDomain 而不是整個池的原因。

Answer 1

您在另一篇文章中喜歡的文章實際上在這方面做得非常好。

立即回收

• Web.config 更改
• Machine.config 更改
• Global.asax 更改
• bin目錄變化
• App_Code 更改

延遲回收

可能會在其他位置發生多次更改，但通常我只注意到對 .aspx 或 .cs/.vb 文件的更改。 添加臨時文本、csv 或其他文件並沒有給我帶來問題。

注意：這些都是應用程序域回收，而不是池的實際回收。 通常，應用程序池將僅根據 IIS 中的設置（請求數、內存限制、空閑時間或計划重啟）進行回收。

Answer 2

兩種不同的效果：

• AppPool 進程是潛在的多個 AppDomain 的宿主。 通常，這可以通過許多效果來回收。 這些可能是時間（每n小時）、請求不足、內存使用等； 所有在 IIS 配置管理器中配置。

• AppDomain（應用程序根的托管實例）可以更頻繁地循環，而不會影響 AppPool 中的其他 AppDomain。 Tess 關於 AppDomain 回收的帖子非常有見地。

您正在寫入受監視以進行重新編譯的文件夾。 這將在某個時候觸發 AppDomain 重新創建。

事件日志將幫助您確定啟動回收的原因。

Answer 3

您可能想要打開完整的 AppPool 回收事件日志：

cscript adsutil.vbs Set w3svc/AppPools/DefaultAppPool/LogEventOnRecycle 255 

您可能還想看看這篇 Scott Guthrie 博客文章： http ://weblogs.asp.net/scottgu/archive/2005/12/14/433194.aspx，它展示了如何在 Global.ASAX 中編寫代碼以記錄Application.End 事件的實際原因。

這對我們診斷幾個棘手的問題非常有用 - 特別是一個將日志文件寫入 wwwroot 目錄的應用程序 - 太多的文件更改導致回收......

Answer 4

這可以根據偏好每天發生，或者在超過進程的最大虛擬內存時發生。

Answer 5

這是一個設置，您可以根據應用程序池運行的分鍾數或已處理的請求數對其進行操作以回收應用程序池。

它還將回收 web.config 更改和已在此處發布的其他內容。

IIS 重置也可以解決問題，停止/啟動服務也是如此。

Answer 6

w3wp.exe出錯了。 這導致Application_Start在Global.asax中被調用。

為了找出答案，我打開了Event Viewer 。

在Windows Logs下，我去了Application 。

我看到一個應用程序錯誤：

Faulting application name: w3wp.exe, version: 10.0.16299.15, time stamp: 0x0aeb5595
Faulting module name: KERNELBASE.dll, version: 10.0.16299.334, time stamp: 0x6369e29f
Exception code: 0xe0434352
Fault offset: 0x0000000000014008
Faulting process id: 0x2900
Faulting application start time: 0x01d43b16f726cbb9
Faulting application path: c:\windows\system32\inetsrv\w3wp.exe
Faulting module path: C:\WINDOWS\System32\KERNELBASE.dll
Report Id: 998cf55d-2cd9-4b8d-9884-2110e3fd1411
Faulting package full name: 
Faulting package-relative application ID: