我的問題是基於這樣的觀察：自從推出 64 位元 Windows 以來，我周圍的許多人似乎都陷入了與頁面檔案相關的系統鎖定。例如，像zeros(2e5)MATLAB 中那樣簡單分配不只是 1600 kB 的零，而是 160 GB。由於 64 位元位址空間，這個數量可以被尋址，但通常不能在 RAM 中尋址。 （我可以舉出很多這樣的例子，它們都減少了記憶體分配。）因此，Windows 求助於使用頁面文件，並在磁碟上儲存 160 GB 的零。只有在此之後（或強制關閉），您的系統才會再次回應。
在 32 位元 Windows 中，最多 4 GB 的位址空間很大程度上避免了這個問題。
那為什麼微軟仍然預設配置大頁面檔案呢？根據我的觀察，預設大小隨著 RAM 的增加而增大，這並沒有什麼意義，除非你有一個非常大、非常快的驅動器，例如非常昂貴的 SSD。出於這個原因，我傾向於在 64 位元 Windows 安裝上關閉頁面檔案。還是我不應該？支持或反對這樣做的理由是什麼？
答案1
Windows 不像 Linux 那樣進行記憶體的惰性分配，可分配的記憶體量取決於頁面檔案。
在 Linux 上，假設任何「稀疏」記憶體分配都不會被充分利用，因此它允許程式不斷過度分配內存，直到物理耗盡為止。如果程式實際上滿足了其提交的內存，但沒有足夠的 RAM 或交換來滿足需求，那麼它將開始殺死進程。
Windows 則相反，並假設所有分配的記憶體最終都會被使用，因此所有保留都會被遵守，直到滿足實體記憶體 + 頁面檔案大小。如果程式能夠分配內存，那麼它就能夠使用它。如果無法分配內存，則已達到 RAM 和頁面檔案大小的限制。
透過停用頁面文件，分配未使用的記憶體的程式（即它假設有頁面文件）可能會導致您在仍有一些「空閒」記憶體時耗盡記憶體。
如果您想在 Windows 系統上使用所有 RAM，那麼您應該透過為其提供一個頁面檔案來讓系統按預期運行。
答案2
頁面檔案為作業系統提供了兩個主要好處，這兩個好處都不受 64 位元作業系統的顯著影響。
- 頁面文件增加了提交限制。
當應用程式分配記憶體時，Windows 作業系統承諾或承諾為其提供足夠的可用儲存空間，即使在最壞的情況下也是如此。該儲存可能位於 RAM 或頁面檔案中。提交限制定義為 RAM 大小加上頁面檔案大小減去少量開銷。如果沒有頁面文件，提交限制將略小於 RAM 大小。記憶體管理器追蹤分配的記憶體總量，以確保它永遠不會超過提交限制。
如果沒有頁面文件，提交限制是硬限制，在作業系統運行時無法增加。使用預設頁面檔案配置，提交限制不僅要大得多，而且是一個軟限制，可以在必要時透過擴展頁面檔案來增加。
在 Windows 中達到提交限制是件壞事。大多數應用程式不能很好地處理這種可能性，而且作業系統本身通常無法容忍它。
- 頁面檔案優化 RAM 使用。
在任何給定時間，電腦都可能包含大量長時間未存取的數據，並且實際上在會話期間可能永遠不會存取這些數據。記憶體管理器當然無法知道這些資料有多重要，因此它必須將其保存在某個地方。
將所有這些很少使用的資料儲存在高速 RAM 中是對這一寶貴資源的嚴重濫用。如果 RAM 沒有這個負擔，就會有更多的記憶體可供應用程式使用和快取。快取在現代作業系統中確實非常重要，並且是良好效能的主要貢獻者。
頁面檔案為記憶體管理器提供了一個可以卸載這些很少使用的資料並減輕 RAM 負擔的地方。這樣做確實會產生成本，但請記住，這是很少使用的數據，因此應該不會很嚴重。記憶體管理器有許多最佳化來最小化這種成本。
但不要將其視為成本，而應將其視為對性能的投資。正如用金錢進行明智的投資是一件好事一樣，記憶體管理器在使用頁面文件上投入了一些時間，因為預期它將在以後帶來巨大的紅利。它通常有效。
這不是什麼新想法。它已經在 Windows 和 Linux 中使用了很多年，而且更早之前就在大型電腦系統中使用了。這是一條久經考驗且真實的原則，並經過數十年的優化。
最重要的是，讓 Windows 按照自己的意願管理頁面文件。設計師知道他們在做什麼。不幸的是，微軟並沒有很好地向用戶傳達這一點，並且存在許多誤解。您在 Internet 上讀到的有關頁面文件的大量內容至少都包含嚴重錯誤。