一、寫在前面
最近學習 docker 過程中遇到 --oom-score-adj 和 --oom-kill-disable 的參數，所以就查閱資料簡單了解下OOM並加以記錄，並沒有看過內核相關的書籍（菜雞一個 -_- | |），各位路過的道友有好書可以推薦下，十分感謝，mua~~
二、什么是OOM
OOM 就是 out of memory 的縮寫，當“不合格”的程序運行在你的系統上，它會吃掉你所有的內存資源，導致kernel無法分配內存在其它進程（OOM）。雖然系統管理員可以增加內存來臨時解決問題，但想從根本上解決還是要處理掉這個問題程序。不過在管理員干涉之前，遇到 OOM 時 kernel 也有自己的處理方式，這要根據 OOM 的參數來進行相應的處理。
三、OOM相關參數
1. /proc/sys/vm/panic_on_oom
-
Arguments
-
值為0：表示啟動 OOM killer。
- 當 panic_on_oom的值為0或者上一步沒有觸發 kernel panic，kernel 就會檢查/proc/sys/vm/oom_kill_allocating_task。
-
值為1：表示有可能會觸發 kernel panic，也有可能啟動 OOM killer。
-
值為2：表示強制觸發 kernel panic，內核崩潰GG。
-
2. /proc/sys/vm/oom_kill_allocating_task
-
Arguments
- 值為0：會 kill 掉得分最高的進程（怎么計分的往下看）
- 值為非0：會kill 掉當前申請內存而觸發OOM的進程
- 當然，一些系統進程（如init）或者被用戶設置了oom_score_adj的進程等可不是說殺就殺的。
3. /proc/sys/vm/oom_dump_tasks
-
Introduction
- 作為系統管理員，我們肯定希望不管是出現 kernel panic 或者 OOM killer 的情況都能夠留下些類似日志的東西，讓我們能了解出現此種情況的原因，oom_dump_tasks參數可以記錄進程標識信息、該進程使用的虛擬內存總量、物理內存、進程的頁表信息等等。
-
Arguments
-
值為0：關閉打印上述日志。在大型系統中，可能存在有上千個進程，逐一打印使用內存信息可能會造成性能問題。
-
值為非0：有三種情況會打印進程內存使用情況
- 由 OOM 導致 kernel panic 時
- 沒有找到符合條件的進程 kill 時
- 找到符合條件的進程並 kill 時
-
4. oom_adj、oom_score_adj 和 oom_score
-
Introduction
- 之所以放在一起，是因為這三個參數的關聯性比較緊密。這三個參數都和具體的進程相關，所以位置都是在 /proc/進程PID/ 目錄下。假設現在已經選擇的是出現 OOM 的時候啟動 killer，那么 kill 哪個進程呢？那就要看它們的的分數了，分數越高 G 的越快。（突然覺得做學渣還是蠻幸福的 _ ）
- 內核會對進程打分（oom_score），主要包括兩部分，系統打分和用戶打分。系統打分就是根據進程的物理內存消耗量；用戶打分就是 oom_score_adj 的值。如果用戶指定 oom_score_adj 的值為 -1000，也就是表示禁止 OOM killer 殺死該進程。
- 用戶可以通過調整 oom_score_adj 的值來決定最終 oom_score 的值，oom_score_adj 的取值范圍是 -1000～1000，為0時表示用戶不調整 oom_score。另外，root進程擁有3%的內存使用特權，因此做最終 oom_score 計算時需要減去這些內存使用量。
- oom_adj是一個舊的接口參數，其功能類似oom_score_adj，為了兼容，目前仍然保留這個參數，當操作這個參數的時候，kernel實際上是會換算成oom_score_adj。
四、參考資料
寫作不易，轉載請注明出處，謝謝~~