在上大學的時候老師提到過這麽一個知識點

32位程序的尋址能力是2^32，也就是4G。對於32位程序只能申請到4G的內存。而且這4G內存中，在windows下有2G，linux下有1G是保留給內核態使用，用戶態無法訪問。故只能分配2G、3G的內存使用。

前幾天服務器報警了，無法負載更多的用戶進行訪問。趕緊看了下程序的自我評分，顯示內存占用達到3.6G，無法繼續工作。

WTF？3.6G？超過linux下32位程序只能使用3G內存的限制？

這個時候懷疑是評分程序寫錯了，趕緊用TOP看了下內存，也達到了3.4G……這就很尷尬了。

這個時候又開始懷疑運維他們裁剪過內核，修改了系統保留內存。

不過這都事猜測，幹脆寫代碼，直接一次malloc10M內存，榨幹系統為止。

然後統計一共分配了404次，接近4G內存了……靈機一動的我又在32位的服務器上重新跑了一次，這次確實分配3G內存之後就榨幹了。

得出結論：64位系統下的32位程序不受到系統保留內存的限制，可以實打實的用到4G內存，畢竟系統有64位的尋址能力沒必要再去和你的小底盤上搶資源了不是。

置於程序評分3.6G，實際使用3.4G，我又去追蹤了一下評分程序，發現一個很蛋疼的事情……這個所謂的內存統計是調用getrusage函數得到ru_maxrss來顯示的，大概的意思是曾經最大常駐內存占用值（又要扯到虛擬內存去了……不扯遠了）。為啥說大概是……因為我實在沒找到明確的文檔，只知道是英文maximum resident set size的縮寫，然後根據我的測試分配內存的時候他不斷上漲，釋放內存之後卻沒下降過。

不知道當初寫這個功能的人為啥要用這個來實現內存統計打分，感覺沒啥意義，因為評分上去之後服務器就拒絕服務了，導致請求由其它的服務器處理，最終所有的服務器全部拒絕服務……而且旁邊就是一段被註掉的函數，裏面是正確的從proc裏面讀取內存占用情況的代碼。

然後就是……這個打分統計出來的CPU使用情況和top看到的也不一樣，打分的cpu占用才0.幾%，而top看占用達到了20~30%，算上cpu核數之後還是不太正確，估計又是一個坑……

先記錄這麽多，等這段時間把資料片忙完之後再來研究……

最後吐一句……當時直接開發64位程序不就沒這麽多麻煩了，現在是內存不足只能靠多進程來彌補，但是多進程反而導致浪費了大量的內存，cpu卻比較閑置。明明64位多線程就能好好服務的事情弄個32多進程弄了這麽多麻煩事。

關於32位程序的內存