IIS 6.0 應用程式集區自動回收機制深度解析：重疊回收、工作進程對應與 Global.asax 陷阱

為何需要應用程式集區回收？

長時間運行的 ASP/ASP.NET 應用程式常因記憶體洩漏、未釋放的非受控資源、靜態物件累積導致 w3wp.exe 進程記憶體/CPU 持續增長，手動重啟網站雖能暫時恢復，但非長久之計。IIS 6.0 引入應用程式集區自動回收機制解決此問題。

應用程式集區與工作進程關係

• 每個應用程式集區由一個工作進程 (w3wp.exe) 服務 (單進程模式) 或多個 (Web 園藝模式)。
• 不同集區的工作進程相互隔離，一個集區崩潰不影響其他集區。
• 任務管理器中可見多個 w3wp.exe，各對應一個活躍集區。

任務管理器：兩個 w3wp.exe 分別對應 KefuAppPool 與 ReportServer 集區

查看 PID 對應集區：iisapp.vbs 指令

1. 任務管理器 → 檢視 → 選擇欄位 → 勾選「PID (處理序識別碼)」。
2. 命令列執行：cscript iisapp.vbs (或 iisapp -a)。
3. 輸出範例：
   W3WP.exe PID: 3232 AppPool: KefuAppPool
W3WP.exe PID: 3572 AppPool: ReportServer

重疊回收示意：回收期間新舊進程共存，舊進程處理完現有請求後退出

四種回收觸發條件與建議設定

重疊回收機制

• 預設啟用：回收時先啟動新工作進程，新進程準備就緒接收請求後，再優雅關閉舊進程 (等待現有請求完成，逾時則強制終止)。
• 優點：零服務中斷，用戶無感知。
• 關鍵參數：ShutdownTimeLimit (預設 90 秒) 控制舊進程最大優雅關閉等待時間。

重大陷阱：Global.asax Application_Start 不會在回收後自動執行

機制： IIS 回收集區後，新工作進程啟動，但只有收到第一個 HTTP 請求時 才會觸發 Application_Start。若網站長時間無訪問 (如夜間)，排程任務、快取預熱、定時器初始化等邏輯不會執行。

解決方案

1. 應用程式初始化模組 (IIS 7.5+ 內建 / IIS 7.0 獨立安裝)： 在 applicationHost.config 設定 preloadEnabled="true" + startMode="AlwaysRunning"，配合 <applicationInitialization> 指定預熱頁面。
2. 外部排程喚醒： Windows 排程工作每小時呼叫 curl https://site/warmup.aspx 觸發 Application_Start。
3. 避免在 Application_Start 執行關鍵業務初始化： 改用靜態建構函式 + 雙重檢查鎖、或 Lazy<T> 延遲初始化模式。

最佳實踐總結

• 啟用每日排程回收 (03:00) + 私人記憶體限制 (依實測設定) 雙重保護。
• 監控 w3wp.exe 記憶體/CPU 趨勢 (效能監視器/SCOM/Zabbix)，動態調整閾值。
• 部署應用程式初始化 解決回收後冷啟動問題。
• 重要排程任務移至 Windows Service / Hangfire / Quartz.NET 獨立進程，勿依賴 IIS 生命週期。