我想優化頁面文件大小以滿足我的實際需求。我想遵循 Mark Russinovich 建議的公式：最小值應為峰值提交減去實體 RAM，最大值應是該值的兩倍。
為了確保我所做的一切都是正確的，我想澄清以下幾點：
1）這個紅色的數字是不是Russinovich先生提到的Peak Commit？
螢幕上是系統資訊視窗流程瀏覽器
2）在“控制面板”>“系統”中，它說我的安裝的 RAM 為 4 GB，只有 2.45 GB 可用。顯然，在任務管理器中我的總實體記憶體也是 2509 MB。那是因為我的作業系統是 32 位元的。所以，我是否正確理解這個 2509（不是那些 4GB）是我應該用於頁面檔案大小計算的數字？
我知道問這個問題可能很愚蠢，但正如我已經說過的，我想確保我做得正確。
非常感謝。
答案1
毫無疑問你指的是“突破 Windows 的極限：虛擬記憶體”作者：馬克‧魯西諾維奇。
- 是的，就是這個數字。
- 是的，您只有 2.5 GB RAM 可用（大約 - 這裡不需要過多的精度）。
然而..你寫的是「正確做事」。我必須指出，馬克的文章是關於「突破極限」的，這個公式給了你一個絕對最低限度對於頁面檔案大小。如果您希望系統效能良好，您就不想「突破極限」。
那篇文章中沒有任何建議說你應該將設定設定得那麼小。只是如果你真的想的話，你可以逃脫它。 （假設您實際上不再需要更多提交的記憶體。）
（您可能還需要更多。請記住，您在這裡看到的這個「峰值」只是Process Explorer 運行期間的峰值。只有當您碰巧在那段時間運行最大應用程式工作負載時，它才有意義。 ，誰說您永遠不會在典型工作負載中添加另一個應用程式？ 因此，您透過監控工具獲得的資訊並不能保證您絕對不需要更多。
請注意，如果您碰巧再次達到該峰值，並且您已將頁面文件設置為您以這種方式計算的最小值，則 RAM 中將沒有空間供映射文件（例如代碼文件，如 exe 和 dll）使用。 。 （這是因為「提交的」虛擬記憶體的計數不包括代碼頁或映射檔案支援的其他頁。）由於程式碼必須在 RAM 中才能執行，所以這是一個問題。
好的，既然您啟用了頁面文件擴展，那麼這不是一個“showstopper”問題。但這肯定會對性能造成影響。
因此，除非您出於某種學術原因嘗試證明不會導致應用程式崩潰的絕對最小頁面檔案大小，無論效能問題如何，否則我不會這樣做。 （我想不出這樣做的實際理由。）
如果你真的想把事情削減到實際的最小值，即不限制可用於程式碼的 RAM，只需將頁面檔案最小大小設定為觀察到的最大提交費用。這意味著即使應用程式和作業系統創建了這麼多已提交的記憶體（並引用了所有記憶體），仍然會有可用於程式碼的 RAM。
也沒有理由將最大大小限制為最小值的 2 倍，除非您非常關心磁碟使用情況。
您會看到，頁面檔案大於系統所需的大小並沒有什麼壞處（除了磁碟空間使用之外）。特別是，比必要的更大的頁面文件不會「吸引」更多的分頁。讓它僅僅足夠大（同樣，除了磁碟空間使用之外）沒有任何優勢。那為什麼還要麻煩呢？即，除了本練習佔用的磁碟空間之外，您沒有「最佳化」任何東西。
鑑於超出提交限制可能會導致應用程式崩潰（從而導致資料遺失），並且在極少數情況下甚至會導致系統崩潰，因此我不會對使頁面檔案盡可能小感興趣。
另一方面，如果系統必須大量寫入頁面檔案 - 在只有 2.5 GB RAM 可用的 Windows 7 系統上，我想它會 - 擁有一個比系統將使用的大得多的頁面檔案加快速度。為什麼？因為如果有大量可用空間，用於頁面檔案的空間分配演算法可能會快得多。
因此，我希望看到頁面檔案 % 使用率的 PerfMon 計數器保持在 25% 以下。