方案一：異常中斷導致日誌寫入死循環
現象
機器在調試或運行 IIS 時異常中斷（如斷電），重啟後 IIS 啟動網頁即佔用 CPU 100%，重開機無效。
原因
中斷瞬間 IIS 寫入異常日誌時產生亂碼，導致 IIS 陷入持續寫日誌的死循環，耗盡資源。
解決
- 刪除
%SystemRoot%\System32\LogFiles\W3SVC1 下當天的錯誤日誌檔（如 ex060904.log）。
- 重新啟動 IIS（
iisreset）。
方案二：程式碼不合理導致 w3wp 與 SQL 進程 CPU 飆高
環境
Win2003 + IIS + ASP + MSSQL
現象
間歇性網站極慢或逾時，w3wp.exe 佔 CPU 70~80%，SQL 佔 20~30%，遠端管理也變慢。
排查流程
- 初步排除： 程式碼無過度使用 Application/Session、無第三方軟體衝突、資料庫結構正常。
- 鎖定嫌疑： 推測為某 SQL 站點程式碼有死循環或低效查詢，導致 IIS 與 SQL 同時飆高。
- 隔離應用程式集區： 為每個 SQL 站點建立獨立應用程式集區。
- 對應 PID： CMD 執行
iisapp -a 記錄各集區 PID，觀察故障發生時哪個 PID 佔用高。
- 定位問題站點： 依 PID 找到對應集區與站點，進一步檢視程式碼或 SQL 查詢效能。
方案三：應用程式集區回收與 CPU 監視設定
記憶體洩漏對策
- 每站點獨立應用程式集區，互不干擾。
- 設定集區回收條件：
• 固定時間回收（預設 1720 小時，可縮短）
• 記憶體超過閾值（如 500 MB）自動回收。
CPU 過高對策
- 啟用集區「CPU 監視」：限制單一集區 CPU 使用率（如 4 核心伺服器設 25%）。
- 設定「每分鐘重新整理」，超過限制時關閉工作進程。
快速對應 PID 到集區
- 工作管理員 → 檢視 → 選擇欄位 → 勾選 PID。
- CMD 執行
iisapp -a（首次會提示註冊腳本，再執行一次即可）。
- 對照 PID 找到集區名稱，再至 IIS 管理員查看該集區屬於哪個站點。
總結建議
- 優先啟用「獨立應用程式集區」+「記憶體/CPU 監視回收」，可大幅降低單一站點拖垮全站風險。
- 若問題持續，必須從程式碼層面優化 SQL 查詢、移除死循環、檢查 Session/Application 濫用。
- 定期清理 IIS 日誌目錄，避免磁碟空間不足或損毀日誌引發異常。
