為什麼Windows 2008 在記憶體滿之前使用swap？
我管理執行 IIS 和 .NET4 Web 應用程序的 Windows 2008 伺服器（嗯，在 Amazon EC2 上）。前幾天我收到了記憶體警報，然後去查看，果然程序記憶體通過某種緩慢的洩漏隨著時間的推移而增長。它並沒有增長太多，就像從 60M 到 200M 一樣，但是盒子上發生了足夠多的其他事情，以至於它超過了我們相當低的門檻值 (75%) 來觸發監視器。
我回收了應用程序的池並釋放了記憶體，在查看統計資訊時我注意到交換空間正在被大量使用，並且超過 1 GB 的記憶體被回收釋放。
也許這是一個基本問題，但我是一個 UNIX 人，我習慣於交換直到你記憶體不足時才習慣。這個盒子的記憶體使用率從未超過 75%。這是 Windows 的東西、.NET 的東西還是亞馬遜的東西？我懷疑這個應用程序中的記憶體洩漏比想像的要大得多——它沒有從 60M 洩漏到 200M，而是從 60M 洩漏到 1.2GB，但其中大部分以某種方式變得“冷”並被推出交換？
我在應用程序池上設置了記憶體回收，但它會觸發盒子滿記憶體，所以這個應用程序在自動回收之前可能會變得非常非常大。
我可以設置定期的“定時”回收，但這是一種解決方法，我會讓開發人員修復應用程序，但需要了解交換使用的情況，以確保我理解正確。
編輯更多資訊：實例記憶體：1.7 GB 交換：4.5 GB
我在 taskmgr 中看到 w3wp.exe 程序顯示記憶體：211,000k。但是當我重新啟動它時（它在它自己的應用程序池中，並且它是盒子上唯一的應用程序），它的記憶體使用量下降到正常的 60M 起點，並且也釋放了 1 GB 以上的交換空間。在 taskmgr 中，我剛剛啟動了通常的記憶體（私有工作集）狀態，但通過我的其他監控（Cloudkick）看到了交換變化。今天回過頭來看，記憶體恢復到 195M（總共 1.2 GB），交換從 1.0 GB 爬到 1.1 GB，並沒有完全恢復到原來的位置（隨著時間的推移，這是一個緩慢蠕變）。
我不太關心這個特定的應用程序，而更關心的是理解 Windows 何時交換以及它如何使用它，以及在給定 Windows 記憶體和交換使用情況時應該關注什麼。
Windows 和 linux 有兩種不同的頁面/交換策略。
Linux
Linux 想要完全避免使用交換空間，並一直等到最後可能的時刻。如果您在 linux 中看到大量交換，則您的系統可能正在或曾經有問題。這種策略有利於最小化整體磁碟 i/o，這是系統中最慢的部分，但對於輕負載和重負載交替週期的系統（老實說，這是我們大多數人）較弱。你的負載已經很重的時候現在將被“額外的”磁碟 i/o 所負擔，或者，換句話說，你需要設計你的伺服器建構，考慮到有足夠的記憶體，即使在最高的預期載入時間。
視窗
Windows 希望將記憶體視為頁面文件的單純記憶體。您的真實記憶體始終在磁碟上，但如果可以，它將首先從“記憶體”讀取/寫入。這個策略有利於隨著時間的推移平衡你的負載；當系統繁忙並需要交換頁面時，目前頁面已經在磁碟上，並且一半的工作已經完成。這種方法在 Windows 還很年輕的時候非常有意義，32MB（忘記 GB）仍然是很多 RAM，並且經常需要使用交換空間是給定的。即使在今天，這對於在輕負載和繁忙負載之間交替的工作負載也是有益的，因為它有助於隨著時間的推移更均勻地分佈磁碟 i/o。
現代 Windows 版本具有額外的優化（例如 SuperFetch），可以在負載較輕時在磁碟和 RAM 中預載入和準備記憶體頁面，以幫助避免在首次載入程序時需要額外的磁碟寫入。所有這一切意味著您可以將系統設計為只需要足夠的 RAM 來滿足低於最高預期負載的需求，因此您仍然可以始終保持至少可接受的性能，同時降低成本。
收斂
這種首先在測試環境中測量或預測負載，然後在負載已知時分配生產資源的概念是系統建構中相對較新的發展，部分隨著虛擬伺服器和雲伺服器的出現而成為可能或至少實用. 根據您的負載，您甚至可以將系統設計為根本不需要交換。在這些情況下，Windows 確實允許您關閉分頁，並且其行為更像 linux 系統。但是，您必須小心；如果您的系統設計需要比預期更多的記憶體，您可能會以這種方式陷入困境。
另一方面，現代 linux 核心比以前更願意機會主義地交換到磁碟。因此，兩個系統之間的記憶體管理策略差異仍然存在，但現在不像以前那麼明顯了。兩種系統都有其優點，每個系統都在觀察對方，看看他們可以複製哪些進步。