1. commit limit與current commit charge

接上文，我們看到testlimit -r開關，只是預留虛擬記憶體，並沒有實際進行提交(commit)。預留虛存並不儲存資料或程式碼，但有時候應用需要這個預留（就像預訂坐位一樣），用以建立大塊虛存，並且在需要的時候進行提交，以確保提交的記憶體在地址空間上是連續的。當程序提交一塊虛存時，作業系統要確保儲存在記憶體裡的資料要麼全部在記憶體裡，要麼全部在硬碟中。這意味著程序的執行有另外一個限制：commit limit。

commit limit是實體記憶體和頁檔案大小的總和。事實上，並不是所有實體記憶體被計算在內，因為作業系統預留了一部分給自己使用。所有存活程序提交的虛存的總和，稱之為current commit charge，它不能超過系統的commit limit。當commit limit值達到時，虛存的分配就會失敗。這意味著標準的32位程序，在達到2GB地址空間限制之前，有可能會出現虛存分配失敗。

current commit charge和commit limit由程序管理器來跟蹤，其資料顯示如下圖：

在Vista和Win2008之前的版本，可能顯示的不叫current commit charge和limit，而採用的是current commit change ("PF Usage")，實際上就是page file usage:

在Vista和win2008下，工作管理員不顯示commit　charge圖，只給出current commit charge和limit值，表示為"Page File"

你可以使用Testlimit -m 來對commit limit進行壓力測試，讓它強行分配已提交記憶體。32位版本的Testlimit在達到commit limit之前可能不會碰到地址空間的級限，這要依賴於實體記憶體的大小、虛存頁檔案的大小以及current commit charge值的大小。如果在32位windows下執行，並且要看看在達到commit limit時系統的行為，可以多執行幾個Testlimit例項，直到有一個在用盡地址空間之前，達到commit limit。

注意，預設情況下，頁檔案是動態增長的，那意味著commit limit也會動態增長（在commit charge變大並且接近它時），並且，即使頁檔案達到它的最大值，系統也會放掉部分記憶體，進行內部調節，就如同普通的應用程式快取完資料以後，會放掉一部分記憶體一樣。Testlimit在達到commit limit之後，會sleep幾秒鐘，接著嘗試分配更多記憶體，不斷重複，直至被強行終斷。

如果你執行的是64位的Testlimit, 幾乎可以肯定的是，在用盡地址空間之前，它就會達到commit limit，除非實體記憶體和頁檔案大小加起來能超過8TB，這個8TB在第一節裡，已經描述了，它是64位應用可以訪問的地址空間。這裡是64位Testlimit在8GB記憶體的系統上（指定每次分配100M）的執行過程中的部分結果：

相關推薦