OOM 殺手如何決定首先殺死哪個程序?
這個答案解釋了核心在遇到 OOM 情況時基於 的值所採取的措施
sysctl vm.overcommit_memory
。當
overcommit_memory
設置為 0 或 1 時,overcommit
啟用,並且允許程序分配比實際可用更多的記憶體。現在,當我們在這種情況下記憶體不足時會發生什麼?OOM 殺手如何決定首先殺死哪個程序?
如果記憶體被程序耗盡,到了可能威脅到系統穩定性的程度,那麼OOM殺手就會出現。
注意: OOM Killer 的任務是繼續殺死程序,直到釋放足夠的記憶體以供核心嘗試執行的其餘程序順利執行。
OOM Killer 必須選擇要殺死的最佳程序。**這裡的“最佳”**指的是在殺死時將釋放最大記憶體並且對系統來說也是最不重要的程序。
主要目標是殺死最少數量的程序,從而最大限度地減少造成的損害,同時最大限度地釋放記憶體量。
為了促進這一點,核心
oom_score
為每個程序維護一個。您可以在目錄下的文件系統中看到oom_score
每個程序的。/proc``pid
$ cat /proc/10292/oom_score
任何程序的值越高,在記憶體不足的情況下被OOM Killer
oom_score
殺死的可能性就越高。是怎麼
OOM_Score
計算的?在 David 的更新檔集中,舊的 badness() 啟發式方法幾乎完全消失了。相反,計算變成了一個簡單的問題,即程序使用了多少可用記憶體百分比。如果整個系統記憶體不足,那麼“可用記憶體”是系統可用的所有 RAM 和交換空間的總和。
相反,如果 OOM 情況是由給定 cpuset/控制組允許的記憶體耗盡引起的,那麼“可用記憶體”是分配給該控制組的總量。如果超出記憶體策略施加的限制,則會進行類似的計算。在每種情況下,程序的記憶體使用被認為是它的駐留集(它正在使用的 RAM 頁數)和它的交換使用的總和。
這個計算結果是一個百分比乘以十的數字;使用可用記憶體的每個字節的程序將獲得 1000 分,而根本不使用記憶體的程序將獲得零分。這個分數很少有啟發式調整,但程式碼仍然從根擁有的程序的分數中減去少量(30),因為它們比使用者擁有的程序更有價值。
應用的另一項調整是添加儲存在每個程序的 oom_score_adj 變數中的值,該變數可以通過 /proc 進行調整。這個旋鈕允許調整每個程序對使用者空間中OOM殺手的吸引力;將其設置為 -1000 將完全禁用 OOM 終止,而設置為 +1000 相當於在關聯程序上繪製一個大目標。
參考
http://www.queryhome.com/15491/whats-happening-kernel-starting-killer-choose-which-process https://serverfault.com/a/571326