Windows-Server-2003
IIS 6.0 應用程序池何時會因記憶體問題而崩潰？
很長一段時間以來，我們的混合經典 ASP/.NET 站點一直存在記憶體不足問題。基本上，我們看到了幾種不同的情況：
- 發生某些請求（返回 LARGE 記錄集的 SQL 查詢）會導致記憶體急劇飆升（私有和虛擬字節），IIS 工作程序崩潰，應用程序池回收。
- Private Bytes 保持“正常”，但 Virtual Bytes 達到最大值 (~2GB)，IIS 工作程序崩潰，應用程序池回收。
崩潰的 EventID 為：1009、1011 和 1013。
在這兩種情況下，ASP 都會在我們的應用程序日誌中報告記憶體不足消息。
如果我們真的“記憶體不足”，為什麼應用程序中的使用者仍然可以工作，而新使用者甚至無法登錄？這是否意味著不能滿足任何請求？
顯然，IIS 仍然可以處理一些請求——所以答案可能是它取決於具體的請求。也許一個比另一個更“昂貴”？
無論如何，我的最終問題是——應用程序池在什麼時候說足夠了，我必須回收？
我們執行 DebugDiag 並看到一些超過 90% 甚至 100% 碎片的堆，那麼回收是否僅在碎片很高且沒有更多堆空間時才會發生？
這是一個稍微主觀的問題，但我希望我能得到一些關於這個門檻值的輸入！
謝謝。
除非工作程序破壞了您配置的回收標準之一（虛擬字節限制看起來不錯？）或無法響應 ping，否則它不會被回收。
應用程序 (ISAPI) 可以將自己報告為不健康，這會觸發回收，但這發生在相當狹窄的條件下。
您的應用程序在執行時基本上是記憶體碎片，而 OOM 反映了這一點 - 沒有空閒的連續、未分配的記憶體可用於新分配；他們失敗了。
根據描述，您的選擇是：
- 修復分配模式
- 將應用程序的各個部分分成單獨的應用程序池（例如，將 .Net 與 ASP 分開執行）- 並非所有應用程序都可以通過這種方式分解，但對於可以分解的應用程序來說，這是一個輕鬆的勝利。兩個應用程序池 = 2 個（或更多）工作程序 = 每個工作程序地址空間 2GB
- 實現虛擬字節限制以在應用程序池變得太大時回收它
- 實施每日回收以防止應用程序達到其整個記憶體空間碎片化的程度
- 如果您的應用是無狀態的，請嘗試網路園藝；增加 max # worker processes 以防止失敗更長時間
- 在 64 位系統上作為 32 位應用程序執行；為工作程序提供 4GB。
從本質上講，如果（無論如何）堆變得超級碎片化，那麼此時您將處於死亡螺旋中，您需要一個新的工作程序。
IIS 對此沒有內置安全帶，因此在程序達到該點之前對您的程序實施回收限制 - 或者只是說“算了吧，我要 64 位！” 可能是可能的解決方案。