我有一個託管在 IIS 中的 WCF 服務應用程式。啟動時，它會獲取非常昂貴的（就時間和 CPU 而言）資源以用作本地快取。
不幸的是，IIS 似乎相當定期地回收該進程。因此，我嘗試更改應用程式集區上的設置，以確保 IIS 不會回收該應用程式。到目前為止，我已經更改了以下內容：
- 將 CPU 下的間隔限制為 5 到 0。
- 進程模型下的空閒逾時從 20 到 0。
- 回收時的常規時間間隔從 1740 到 0。
這夠了嗎？我對我更改的項目有具體問題：
- CPU下的Limit Interval設定具體是什麼意思？是否意味著如果超過一定的CPU使用率，應用程式集區就會被回收？
- 「回收」到底是什麼意思？該應用程式是否完全拆除並重新啟動？
- 「工作流程關閉」和「應用程式集區回收」有什麼不同？進程模型下的空閒逾時文檔討論了關閉工作進程。雖然回收下的常規時間間隔的文檔討論了應用程式集區回收。我不太明白兩者之間的差異。我認為 w3wp.exe 是運行應用程式集區的工作進程。有人可以解釋一下兩者之間的應用差異嗎？
擁有 IIS7 和 IIS7.5 標籤的原因是應用程式將在這兩個版本中運行，並希望兩個版本之間的答案相同。
參考圖片：
答案1
回收
回收通常*是 IIS 啟動一個新進程作為應用程式的容器，然後讓舊進程ShutdownTimeLimit在被殺死之前自行消失。
*- 通常：請參閱DisallowOverlappingRotation/“禁用重疊回收”設置
這是破壞性的，因為原始進程及其所有狀態資訊都被丟棄。使用進程外會話狀態（例如，狀態伺服器或資料庫，如果您的狀態很小，甚至可以使用 cookie）可以解決此問題。
但它是預設的重疊的- 意味著中斷的持續時間被最小化，因為新進程啟動並連接到請求隊列，然後舊進程被告知“您有 [ ShutdownTimeLimit] 秒時間離開。請遵守。”
設定
對於您的問題：該頁面上的所有設定都以某種方式控制回收。 「關閉」可能被描述為「主動回收」——進程本身決定是時候關閉，並以有序的方式退出。
反應性回收是 WAS 偵測到問題並啟動流程的地方（在建立合適的替代 W3WP 之後）。
現在，這裡有一些可能導致一種或另一種形式回收的東西：
- ISAPI 判定其不健康
- 任何模組崩潰
- 空閒超時
- cpu限制
- 調整應用程式集區屬性
- 作為你媽媽可能有一次尖叫道：「停下來採摘一定要堅持下去，否則永遠不會好起來！
- “ping”失敗 * 實際上並不是 ping 本身，因為它使用命名管道 - 更多“生命檢測”
- 上面螢幕截圖中的所有設置
怎麼辦：
一般來說：
停用空閒超時。 20 分鐘不活動 = 繁榮！舊進程不見了！下一個傳入請求的新流程。將其設為零。
停用固定時間間隔- 29小時違約被各方描述為「瘋狂」、「煩人」和「聰明」。事實上，其中只有兩個是正確的。
可選打開禁止在配置變更時旋轉（多於，禁用配置變更的回收）如果您無法停止使用它 - 這允許您更改任何應用程式集區設置，而無需立即向工作進程發出需要終止它的信號。您需要手動回收應用程式集區才能使設定生效，這使您可以預先設定設置，然後使用變更視窗透過回收程序套用它們。
作為一般原則，離開ping已啟用。那是你的安全網。我見過人們將其關閉，然後網站有時會無限期掛起，導致恐慌......因此，如果設定對於您的響應速度明顯非常非常慢的應用程式來說過於激進，請稍微關閉它們看看你會得到什麼，而不是把它關掉。 （除非您透過自己的監控進程為掛起的 W3WP 設定了自動崩潰模式轉儲）
這足以使一個行為良好的過程永遠存在。如果它死了，肯定會被替換。如果它掛起，則 ping 應該會恢復該狀態，並且新的 ping 應該會在 2 分鐘內開始（預設；最壞情況的計算應該是：最多ping 頻率+ping 超時+啟動時間限制在請求再次開始工作之前）。
CPU限制不是通常情況下有趣的是，因為預設情況下它是關閉的，而且它也被配置為不執行任何操作；如果它被配置為終止進程，當然，這將是一個回收觸發器。丟開。請注意，對於 IIS 8.x，CPU 限制也成為選項。
(IIS) AppPool 不是 (.Net) AppDomain（但可能包含一個/一些）
但是...然後我們進入.Net 領域，以及 App領域回收，這也可能導致狀態丟失。 （看：https://blogs.msdn.microsoft.com/tess/2006/08/02/asp-net-case-study-lost-session-variables-and-appdomain-recycles/）
簡短版本，您可以透過觸摸內容資料夾中的 web.config 檔案來完成此操作（再次與採摘！），或透過在該資料夾中建立一個資料夾，或一個 ASPX 文件，或......其他東西......這就是關於與應用程式集區回收一樣具有破壞性，減本機程式碼啟動成本（它純粹是託管程式碼 (.Net) 概念，因此此處僅發生託管程式碼初始化內容）。
防毒軟體在掃描 web.config 檔案時也會觸發此問題，導致更改通知，從而導致...
答案2
好心檢查，
如果您瀏覽網頁查找應用程式集區配置為定期自動回收的原因，您將很難找到與內存問題無關的合理答案。就好像整個社區已經基本接受了這樣一個事實：我們的 Web 應用程式（或 IIS 中託管的服務層）需要回收以避免記憶體問題。
我一直認為如果您的程式碼需要定期重新啟動才能保持正常工作，那麼顯然有問題。有一個錯誤在程式碼中的某處，您需要修復該問題，而不是偶爾重新啟動進程以使問題「消失」。
確實需要開始更多地關注記憶體管理在 .NET 中並確保我們的應用程式可以毫無問題地繼續運行。
答案3
根據OP場景（啟動/預熱時的長時間初始化），另一件事要檢查是啟動時間限制（秒），預設值為 90 秒。如果初始化時間超過啟動時間限制，則可以終止工作進程。
答案4
答案是，你能阻止 AppPool 回收，但是您不應該。
原因是，如果存在內存洩漏，它最終會耗盡伺服器的所有內存，Windows 將出現藍色屏幕或拋出內存不足異常，從而導致同一 IIS 伺服器上的其他站點癱瘓。
因此，決定該網站允許使用多少內存，並將上述設定設定為在達到該限制時回收。
通常情況下，回收會順利進行，因此最終用戶不會意識到這一點。但如果您使用的是 Blazor Server，則所有會話都在伺服器上執行，並且所有狀態都會遺失。在實踐中，我看到 Blazor 應用程式在回收發生時顯示「正在連接...」訊息大約 5 秒。換句話說，它對於伺服器端 Blazor 應用程式來說並不優雅。
這個故事的寓意就是前面提到的，確保您的網站不會洩漏記憶體。在開發過程的早期測試您的內存，不要等到它上線，因為 Blazor Server 是內存密集型的，並且我的經驗是我必須花費大量時間來調試內存問題。這不是 Blazor 的錯誤，只是 Blazor 伺服器應用程式的本質要求非常嚴格的程式碼。在 .net 的早期，我從不擔心內存，因為 GC 會處理所有這些，但在 IIS 中運行則是另一回事。