最近在預發環境上有一個重要的進程隔三差五就被OOM Killer幹掉（通過查看CentOS系統日誌/var/log/messages揪出來是OOM Killer乾的）。該機器上跑着各種進程，內存是有些喫緊。這當然可以通過加大機器內存或者遷走某些進程來解決。但一時又沒有多餘的機器和內存資源，只能自己動手豐衣足食了（資源短缺確實是更能激發人去思考更優更節省的方案）。現在我要解決的是如下兩個問題：
- 爲什麼被OOM Killer幹掉的是這個進程而不是其他的？
- 能保護某個進程不被OOM Killer 幹掉嗎？
《Surviving the Linux OOM Killer》一文正是對上面兩個問題的介紹。
How does OOM Killer choose which process to kill?
Linux 內核會給每個運行中的進程分配一個叫 oom_score 的分數，它表示當系統可用內存很低時，一個進程被kill掉的可能性有多大。分數越高，越有可能被kill掉。分數值很簡單：等於進程的內存佔用百分比乘以10。比如一個進程佔50%的內存，它的oom_score值就是 50 X 10 = 500 .
一個進程的oom_score被記錄在/proc/$pid/oom_score 文件中。
Can I ensure some important processes do not get killed by OOM Killer?
可以保護重要的進程不被OOM Killer幹掉嗎？還真是可以！
OOM Killer會檢查 /proc/$pid/oom_score_adj文件來調整最終的分數 (oom_score)。所以我們可以通過在這個文件中給一個大的負數，以降低該進程被選中並終止的可能性。oom_score_adj可以在-1000到1000間變化。如果你給了-1000，進程即使使用了100%的內存也不會被OOM Killer幹掉。可通過下面命令修改oom_score_adj(比如設爲-200):
sudo echo -200 > /proc/$pid/oom_score_adj
Caveats of adjusting OOM scores
文章最後給出警告：過多的調整OOM adjusted score 會導致OOM Killer選中進程的過程變得隨機，而且沒有足夠的內存被釋放掉。解決內存不足的最好辦法還是增加可用內存（例如更好的硬件）或者將某些進程移到別的地方去，又或者優化代碼以減少內存消耗。