Linux OOM Killer 保護機制

 發表於 2018-12-25  更新於 2019-04-02  分類於 Linux  閱讀次數： 3

OOM killer（Out Of Memory killer）

linux下允許程序申請比系統可用內存更多的內存，這個特性叫Overcommit（過度分配）。在系統內存耗盡的情況下，OOM killer機制選擇性的干掉一些進程以求釋放一些內存。默認具體的記錄日志是在/var/log/messages中。

參數配置

• 參數/proc/sys/vm/overcommit_memory可以控制進程對內存過量使用的應對策略

1 2 3

overcommit_memory=0，這是缺省值，表示內核將檢查是否有足夠的可用內存供應用進程使用；如果有足夠的可用內存，內存申請允許；否則，內存申請失敗，並把錯誤返回給應用進程。 overcommit_memory=1，內核會永遠認為有充足的內存可用，進程申請內存時總是允許。 overcommit_memory=2，表示系統所能分配的內存不會超過swap+RAM*系數（/proc/sys/vm/overcommit_ratio，默認50%，可以調整），如果這么多資源已經用光，那么后面任何嘗試申請內存的行為都會返回錯誤，這通常意味着此時沒法運行任何新程序。

 

內核決策依據

• /proc/[pid]/oom_adj，該pid進程被oom killer殺掉的權重，一般介於 [-17,15]（具體具體權重的范圍需要查看內核確認）之間，越高的權重，意味着更可能被oom killer選中，-17表示禁止被kill掉。

• /proc/[pid]/oom_score，當前該pid進程的被kill的分數，越高的分數意味着越可能被kill，這個數值是根據oom_adj運算（2ⁿ，n就是oom_adj的值）后的結果，本身oom_score是不能修改值。

兩種進程保護措施

• 修改權重

  1	echo -17 > /proc/[PID]/oom_adj（輸入-17，禁止被OOM機制處理）

   

• 開啟OOM較為的保險機制

  1 2	echo “vm.panic_on_oom=2” >> /etc/sysctl.conf systcl -p

  panic_on_oom(/proc/sys/vm/panic_on_oom)

  決定系統出現oom的時候，要做的操作。接受的三種取值如下：
  0 - 默認值，當出現oom的時候，觸發oom killer
  1 - 程序在有cpuset、memory policy、memcg的約束情況下的OOM，可以考慮不panic，而是啟動OOM killer。其它情況觸發 kernel panic，即系統直接重啟
  2 - 當出現oom，直接觸發kernel panic，即系統直接重啟
  3，oom_adj、oom_score_adj和oom_score
  准確的說這幾個參數都是和具體進程相關的，因此它們位於/proc/xxx/目錄下（xxx是進程ID）。假設我們選擇在出現OOM狀況的時候殺死進程，那么一個很自然的問題就浮現出來：到底干掉哪一個呢？內核的算法倒是非常簡單，那就是打分（oom_score，注意，該參數是read only的），找到分數最高的就OK了。那么怎么來算分數呢？可以參考內核中的oom_badness函數：
  ————————————————
  版權聲明：本文為CSDN博主「Leonban」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處鏈接及本聲明。
  原文鏈接：https://blog.csdn.net/hearbeat/article/details/82793258

   

參考

https://www.linuxba.com/archives/7744