ASP.NET 應用程序池資源控制實戰：限制內存佔用與定時回收優化性能

問題背景

ASP.NET 1.1 時代（.NET Framework 1.1），ASP.NET 處理請求由 aspnet_wp.exe (ASP.NET Worker Process) 承載。長時間運行下，未釋放的托管堆、大對象堆碎片、第三方組件泄漏，導致工作進程內存持續增長，最終拖垮整台服務器。雖然 IIS 6 引入應用程序池機制，但在 .NET 1.1 中仍需通過 machine.config 微調 <processModel> 節點來實現資源管控。

配置文件位置與關鍵節點

C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFIG\machine.config

尋找 <processModel> 區段，核心屬性調整建議：

配置示例

<processModel 
    enable="true"
    timeout="03:00:00"
    idleTimeout="00:20:00"
    memoryLimit="40"
    requestLimit="10000"
    responseRestartDeadlockInterval="00:03:00"
    />

原理與效果

• 定時重啟： 類似 IIS 6+ 應用程序池的「定期回收」，定期釋放非托管資源、大對象堆碎片、終結器隊列積壓。
• 內存上限： 當 aspnet_wp.exe 私有工作集超過物理內存 40%，運行時自動啟動新進程平滑接管新請求，舊進程完成現有請求後退出，實現「零停機」回收。
• 閒置關閉： 低峰期自動釋放資源，適合多站點共享服務器場景。

遷移提示：.NET 2.0+ / IIS 6+ 時代的新寫法

自 .NET Framework 2.0 起，processModel 配置廢棄，轉移至 IIS 應用程序池設置（applicationPool.config / IIS 管理器 GUI）：

• 回收條件：固定時間、請求數、內存限制、虛擬內存限制。
• 快速失敗保護：連續失敗次數/時間窗口，防止循環崩潰。
• 重疊回收：新舊進程重疊運行，真正零中斷部署。

雖然 .NET 1.1 已停止支援，但理解進程模型配置思想，對排查現代容器化 .NET Core 應用的內存洩漏、配置 Kubernetes liveness/readiness probe 同樣有啟發意義。