故障現象
- 網站無法打開或極慢，靜態 HTML 正常；
- IIS 日誌記錄：
ISAPI 'asp.dll' reported itself as unhealthy: 'ASP unhealthy because 100% of executing requests are hung...'
- 重啟 IIS 或回收應用程式池暫時恢復，但過段時間復發。
根因分析
- ASP 代碼缺陷導致請求掛起：死循環、長時間資料庫查詢、COM 組件未正確釋放，耗盡執行緒池。
- 預設回收週期過長（1740 分鐘）：記憶體洩漏累積未釋放，最終觸發假死。
- 單一應用程式池承載過多站點：某站點故障波及全池。
解決方案三部曲
1. 縮短回收時間（立竿見影）
- 預設 1740 分鐘（29 小時）→ 建議 120~300 分鐘（2~5 小時）。
- 配合 固定時間回收（如凌晨 05:00） 避開業務高峰。
- 路徑：IIS 管理器 → 應用程式池 → 進階設定 → 回收區段。
2. 應用程式池隔離（治本）
- 單站點：獨立應用程式池，回收 300 分鐘 + 凌晨固定回收。
- 多站點：依流量分組，每池 8~10 站；大流量站點獨享池。雖增加記憶體佔用（每池約 120MB 基線），但換取穩定性極具性價比。
- 操作：網站屬性 → 主目錄 → 應用程式池下拉選單指定。
3. 代碼層面排查（根治）
- 確認
asp.dll 映射正確；
- 啟用 ASP 偵錯，定位長時間執行腳本；
- 優化資料庫查詢、關閉未用 COM 物件、避免無限循環；
- 考慮遷移至 ASP.NET Core / PHP 等現代框架。
輔助工具
可編寫批次腳本或使用第三方監控工具（如 IIS Reset Tool、AppPool Recycler）定時自動回收，並記錄日誌供事後分析。
總結
「縮短回收週期 + 隔離應用程式池 + 代碼優化」三管齊下，可將 IIS 假死發生率降至極低。記住：記憶體洩漏不會自癒，定期回收是低成本的有效緩解手段。
