TOMORROW 星辰 發表於 2020-12-10 16:12:20
為了高效、準確測試出該系統下，單個進程能夠申請到的最大虛存空間，所以編寫了一個Linux的測試程序。因為 64 位真的是個很可怕的數字，所以程序在申請內存空間時，先申請較大的內存塊（100G），直到沒有這麼大的內存塊，然後申請上次能申請到的內存塊的一半。重複以上步驟，直到內存塊變得足夠小（小於 100Byte）。然後結束申請內存。代碼如下：
#include
在終端 1 編譯運行上面代碼。
運行後，先在另一個終端（終端 2）執行：
cat /proc/6674/status
查看該進程的 status 文件如下圖圖一所示：
終端 1 終端 2
圖一
對於 status 文件，本文只會關注以下幾個參數：
VmPeak（進程所佔用的虛存空間最大值）
VmRSS（進程正在佔用物理內存大小）
VmSwap（進程佔用交換區大小）
然後回車開始申請內存，當終端停止輸出數字時，再次在終端 2 執行：
cat /proc/6674/status
得到下圖圖二輸出：
終端 1 終端 2
圖二
對比圖一和圖二中的 VmPeak：
137438953320K – 12044K = 140737475866624 Byte
= 111 1111 1111 1111 1111 1111 0100 0001 0111 0000 0000 0000（B） Byte
是的，如果你沒有眼花，你數到上面得到的是一個 47 位!!!!二進位數。
47 位什麼概念？大概是 128TB = 128*1024GB !!! (試問現在誰的個人電腦有這麼大的硬碟？？更不要說內存)
一個進程能夠申請到這麼恐怖的內存空間？這不但超過了物理內存、超過了物理內存+交換區、還超過了硬碟大小啊。這不科學啊。
但是從 status 讀出來的數據錯不了的。
首先，虛擬內存，顧名思義，虛擬的、並不是事實上存在，在一個進程的虛存空間裡，只存在進程自己和系統內核，而不存在其他進程。這是為了方便編程和提高物理內存利用率而創造出來的一種機制（在過去內存是很貴的）。虛擬內存中對應著的是邏輯地址，邏輯地址通過作業系統和硬體的配合映射到物理內存上。（這裡就不在多說虛擬內存的定義。如果把段頁式內存管理機制理解後，虛擬內存也就理解了。關於段頁式內存管理介紹可參考：深入理解作業系統之——分頁式存儲管理，深入理解作業系統之——段頁式存儲器管理。）
其二，交換區，實際上就是物理內存不夠用時，虛存空間的數據就必須映射到交換區上。
那麼單個進程所能申請的最大虛存空間理應不會超過物理內存和交換區的和。然而實際卻是超過那麼多。
然後，網上查閱相關資料，msdn 上看到了相關解釋。
傳送門：https://docs.microsoft.com/zh-cn/windows-hardware/drivers/gettingstarted/virtual-address-spaces
該文章介紹到，Windows 32 系統下，虛擬內存中，用戶空間佔用了低地址 2G 的空間，系統內核佔用了高地址 2G 空間。總共虛存空間就是 2^32Byte。
圖三
那麼 64 位系統中，就系統而言，總共的虛存空間應當是 2^64Byte？
在該文章下面還有 Windows 64 位系統的虛存空間介紹，如下圖圖四所示。從圖中看到用戶虛存空間 8TB+系統空間 248TB=256TB=2^48 Byte ，這個數字似乎和上面所測得的單個進程能夠申請到的最大虛存空間的數字有點接近了。
圖四
注意看圖四，還可以發現 64 位系統中還有很大很大的虛存空間保留沒有被使用的。從這個出發繼續查閱資料，然後找到了關於目前 64 位 CPU 的相關說明。由於目前還遠遠用不到 64 位那麼大的空間，所以 AMD 64 位 CPU 目前只用了 48 位的尋址。而 Intel 的 64 位 CPU 是和 AMD 交叉授權，所以 Intel 64CPU 也同樣只採用 48 位尋址。所以圖三的保留空間就得到了解釋。
再回到原先的問題，現在知道了就 64 位系統而言，虛擬內存空間是可以達到 2^48Byte 那麼大的，參考 Windows 64 位系統虛存空間結構，可以猜測Linux 64 位系統下，用戶虛存空間和系統內核虛存空間分布和 Windows 是相似的，只是兩者大小比例有所差別。（因為找了很久，沒有找到Linux的官方文檔說明，只找到很舊的、32 位。所以不能提供準確的參考，如果有讀者找到，希望可以告訴作者一下補上）。
不過，到現在，還有問題沒有解決，為什麼所申請的虛存空間會比物理內存與交換區的和大？
現在回到一開始沒有運行完的程序，在終端 1 回車繼續運行程序，程序接著會對所申請到的第一個 100G 內存塊每隔 2M 空間進行寫操作，每回車一次，會寫 1000 次。回車幾次後，在終端 2 再執行：
cat /proc/6674/status
得到下圖圖五：
圖五
由圖五可以看到正在使用的物理內存 VmRSS 變小了，正在使用的交換區空間 VmSwap 迅速增大。但是兩者之和是在一直增加的，這就說明，申請到的虛擬內存在未被使用之前，它只是一個數字，並沒有實際的物理內存和交換區與之相對應。當對虛存進行寫操作時，系統就會逐步分配物理內存，而物理內存的數據又會可能被系統調到交換區。現在問題逐漸明了了。
如果我不停地對虛存空間進行寫操作會怎樣，為了解決疑惑，在終端 1 不停回車，偶爾在終端 2 中查看 status 文件中的狀態，寫到一定程度後，終端 1 出現了
[1] 7893 killed a.out
如圖六所示：
圖六
在進程結束之前查看到的 status 文件顯示 VmRSS+VmSwap 約等 1.8G，加上系統佔用和其他進程佔用，那麼說此時物理內存和交換區已經接近極限了。再繼續運行寫的時候，作業系統為了系統的正常運行選擇把這個進程殺死了。那麼所有的疑問也解決了。
系統所允許的申請的虛存空間是可以超過物理內存與交換區的和的。但是當進程所佔用的物理內存加上交換區影響到了系統的正常運行就會被系統殺死。
編輯：hfy
聲明：本文內容及配圖由入駐作者撰寫或者入駐合作網站授權轉載。文章觀點僅代表作者本人，不代表電子發燒友網立場。文章及其配圖僅供工程師學習之用，如有內容圖片侵權或者其他問題，請聯繫本站作侵刪。 侵權投訴