爲什麼PS出的RSS總和大於實際物理內存

使用ps  aux  查看系統進程時，第六列即 RSS列顯示的就是進程使用的物理內存。
但是把系統全部進程的該列相加時，獲得的總和又遠遠高於系統實際的物理內存？這究竟是怎麼回事呢？
看一看linux是如何管理內存的就會知道。
我理解的意思是這樣的，linux會在每一個進程生成時分配必定量的內存給這個進程，這個只是分配，而體如今ps出來的是VSZ那列，這叫作虛擬內存。但實際上這些進程並無佔用這些內存。不妨，我也借用網上的一個例子來形容一下，就像銀行發工資給員工同樣，每一個員工都有一個本身的銀行卡，每個月銀行都會把固定的錢數打到員工的銀行卡里，可是這個過程並非把實際的錢發到員工手裏，只是一串數字而已。實際上，銀行並無那麼多錢的。回頭再來看看linux給進程分配內存是否是和上面的舉的例子很像呢？
講了上面的觀點後，依然不能把筆者所設的問題解答，那麼繼續往下探討：
把系統全部進程的該列相加時，獲得的總和又遠遠高於系統實際的物理內存？這是由於 ps 的結果，RSS 那部分，是包括共享內存的。這裏使用 pmap 來看看。
pmap -d 24030
24030:   /usr/local/php/bin/php-cgi --fpm --fpm-config /usr/local/php/etc/php-fpm.conf
Address           Kbytes Mode  Offset           Device    Mapping
0000000000400000    6444 r-x-- 0000000000000000 008:00002 php-cgi
0000000000c4b000     272 rw--- 000000000064b000 008:00002 php-cgi
0000000000c8f000      52 rw--- 0000000000c8f000 000:00000   [ anon ]
00000000059dc000    9572 rw--- 00000000059dc000 000:00000   [ anon ]
0000003519000000     508 r-x-- 0000000000000000 008:00002 libfreetype.so.6.3.10
000000351907f000    2048 ----- 000000000007f000 008:00002 libfreetype.so.6.3.10
中間部分省略
00002b757df75000       4 rw--- 000000000000a000 008:00002 libnss_files-2.5.so
00002b757df76000   32768 rw-s- 0000000000000000 000:00008 zero (deleted)
00002b7580685000       4 rw-s- 0000000000000000 000:00008 zero (deleted)
00007fff2e126000     476 rwx-- 00007fff2e126000 000:00000   [ stack ]
00007fff2e19d000       8 rw--- 00007fff2e19d000 000:00000   [ anon ]
ffffffffff600000    8192 ----- 0000000000000000 000:00000   [ anon ]
mapped: 139548K    writeable/private: 12344K    shared: 32772K

pmap是用來顯示內存使用的指令，-d 後面跟的是進程id. 關於pmap的使用以及顯示的數據請看 http://mylinux.5d6d.com/thread-977-1-1.html linux 會把一些shared libraries 載入到內存中，在pmap 的輸出中，這些shared libraries 的名字一般是 lib*.so ,如 libX11.so.6.2.0 。 這個 libX11.so.6.2.0 會被不少process load 到本身的運行環境中，同時，ps 輸出的RSS 結果中，每一個process 都包含了這個libX11.so.6.2.0 ，而事實上它只被load 了一次，若是單純把ps 的結果相加，這樣就重複計算了。 看pmap輸出的結果，其實php-cgi 單純進程所佔的內存是這個writeable/private: 12344K