調研目標： 1、檢查memory cgroup管理的程序都設定為不可oom kill時，當出現oom，是否會造成程序或程序組阻塞。 2、若出現阻塞，是否可自恢復。 一、準備過程 0、執行lssubsys --all，檢查是否安裝了cgroup的元件；沒有安裝則 apt-get install -y cgroup-bin。 1、準備三個程式，其中兩個分別可搶佔記憶體256MB、128MB，最後一個可從0開始逐漸增大記憶體佔用。 2、對debian系統開啟cgroup memmory子系統。（debian預設是關閉該子系統的）。 操作： vim /etc/default/grub 修改GRUB_CMDLINE_LINUX的值為"cgroup_enable=memory"。儲存。 執行update-grub; 執行reboot。 3、建立一個memory限制的cgroup。（執行完步驟2後，memory root cgroup會自動建立並掛載）。 操作： cd /sys/fs/cgroup/memory/ mkdir ts_mem_cg echo 400M > memroy.limit_in_bytes 二、測試過程 1、在ts_mem_cg下啟動程序，並設定為不可oom_kill。 操作： cgexec -g memory:ts_mem_cg /home/test/256MBMem cgexec -g memory:ts_mem_cg /home/test/128MBMem ps aux |grep 256MBMem, 找到pid，echo -1000 > /proc/pid/oom_score_adj ps aux |grep 128MBMem, 找到pid，echo -1000 > /proc/pid/oom_score_adj 對第三個程序，直接啟動/home/test/auto_encrease_mem，該程式會被getchar()阻塞。再開啟一個終端介面執行下面的操作。 ps aux |grep auto_encrease_mem， 找到auto_encrease_mem的pid。echo -1000 > /proc/pid/oom_score_adj。 把程序auto_encrease_mem新增到ts_mem_cg： cgclassify -g memory:ts_mem_cg pid 回到第一個終端響應getchar()，讓程式開始執行，逐漸搶佔記憶體。（這樣操作是為了防止啟動後來不及做oom設定就先oom了）。 2、利用top或free觀察記憶體使用情況。 3、auto_encrease_mem程式不斷申請記憶體並輸出提示，最後提示資訊的輸出中斷。說明發生了oom。 4、對auto_encrease_mem程式增加printf()輸出，多次測試，觀察輸出提示中斷對應的位置。反覆測試確認位置。 5、調整128MB程序的oom_score_adj（，改為預設值0和線上值-900），使其變成可oom kill。多次測試，檢查cgroup程序組的變化，被阻塞的程序auto_encrease_mem是否能脫離阻塞狀態。 三、結果分析 1、多次測試後，發現auto_encrease_mem阻塞在malloc()操作。 此時，三個程式總共佔用記憶體257+129+16=402MB；auto_encrease_mem程序cpu佔用53%（top顯示）。 2、第5步操作後，程序128MBMem隨即被oom kill；程序auto_encrease_mem恢復正常執行（繼續申請記憶體並輸出已用記憶體量提示資訊）。 四、結論 1、依據上述測試，認定在memory cgroup限定的記憶體使用完時(臨近oom)，如果該cgroup管理的程序都不可oom kill，那麼cgroup程序組的程序就有機會在申請記憶體時被阻塞。 2、如果memory cgroup程序組內有程序可被oom kill，則這些程序在oom發生時會被kill掉。記憶體空餘後，之前因oom被阻塞的程序可以恢復執行。 說明： 以上測試在沒有開啟swap盤的情況下進行。 2016-05-10 hzzengchao1