top free命令真的能得到實際記憶體使用狀況嗎？
阿新 • • 發佈：2019-01-04
一.關於Virtual Memory
參考：http://serverfault.com/questions/138427/top-what-does-virtual-memory-size-mean-linux-ubuntu
虛擬記憶體往往是線上程在記憶體中映射了一個很大的檔案，而這個檔案儲存在磁碟上，也需要佔用一個很大的地址空間，交換區的問題撇開不談。
而RES記憶體才是執行緒真正佔用的記憶體*
最準確的，首先要排除其他執行緒的記憶體動態大幅變化的前提下，啟動執行緒，記錄free memory掉的情況，vmstat和free命令都可以
VIRT欄位的man page：
o: VIRT -- Virtual Image (kb) 
這裡存在一個問題，free命令或者top標題部分顯示的used統計資料，和top標題下面的部分的詳細程序的RES的累加，
差別很大，used遠大於RES的累加和
還有一個問題，就是進城的真實佔用記憶體，top命令顯示的是不是偏少？
三.嘗試
我們將之前消耗記憶體很嚴重的協處理器程式，讓他跑起來，監控86機器（87,88,89的free memory太少，資料變化很快穩定，不易觀察），在執行指令碼前後，通過free -m命令和top命令監控記憶體變化情況：
||
||
\/
可見，指令碼執行16分鐘後，86機器：
free memory： 37.4G —> 29.3G
HRegionserver：RES 2.1G —> 2.1G VIRT 3428m —> 3455m
關閉指令碼一段時間：
86機器：
free memory： 37.4g —> 29.3g —> 29.2g
HRegionserver：RES 2.1g —> 2.1g —> 2.2g VIRT 3428m —> 3455m —> 3610m
可見，free memory掉了8個G，但是top命令得到的HRegionserver等process的RES並沒有明顯增加！
仔細觀察top結果（按照m排序）中，各個process的RES都沒有大的變化，其實top下面的關於process的各項指標幾乎都變化不大！
但是，我們觀察到; swap部分：
swap cached：21.7g —> 29.8g —> 29.8g
正好cache佔用增加了8個G
然後，我們參考：
總結來說，就是Linux系統並不是簡單的將記憶體分配給各個process，它還進行了一層記憶體管理
第一.訪問檔案的檔案資料，系統會快取起來，以便以後訪問，就是所說的命中記憶體頁類似的原理，
這部分的檔案快取的處理，直接體現在swap cached統計資料裡面，也體現在VIRT Memory裡面，兩個都是統計資料，只增不減，跟process實際佔用的記憶體不直接相關
我們再使用smem工具分析記憶體的消耗：
=====||||||||=====
====\\\//////====
SMEM工具的右邊三列是USS PSS RSS
free memory： 29.0g —> 20.2g
而smem顯示的habse 114605 process佔用的USS穩定而且還下降了，VIRT記憶體不變，swap cache上漲了8個g
可見我們的process做了很多檔案方面的讀寫活動，導致系統將記憶體分配出去快取這些內容，成為了“被浪費”的used memory，這部分記憶體需要Linux系統去回收
四.問題的進一步解答
top命令顯示的執行緒實際記憶體佔用是RES這一指標，但是所有執行緒的RES數之和與used memeory差別很大（至少是兩倍多）？
參考：http://serverfault.com/questions/377617/how-to-interpret-output-from-linux-top-command
總結就是 ：
（一）：used這個統計量，並不是使用者執行緒佔用記憶體之和，而是Linux系統總共消耗的記憶體，使用者執行緒是“寄生”於Linux OS之上的；
（二）：對於free統計量，是“乾淨的”可以直接分配的記憶體，但是cached和buffered這兩種狀態的記憶體，主要是對映到磁碟的緩衝，也能夠被繼續分配
（三）：真正被使用的記憶體real free memory ＝ used - buffers - cached；真正可用的記憶體real free memory = total - real free memory