Questa risposta spiega le azioni intraprese dal kernel quando si verifica una situazione OOM in base al valore di sysctl vm.overcommit_memory .
Quando overcommit_memory è impostato su 0 o 1, overcommit è abilitato e i programmi possono allocare più memoria di quella effettivamente disponibile.
Ora cosa succede quando esauriamo la memoria in questa situazione? Come funziona il assassino OOM decidere quale processo uccidere per primo?
Risposta accettata:
Se la memoria è esaurientemente utilizzata dai processi, nella misura in cui può minacciare la stabilità del sistema, allora entra in gioco il killer OOM.
NOTA: È compito dell'OOM Killer continuare a terminare i processi finché non viene liberata memoria sufficiente per il buon funzionamento del resto del processo che il kernel sta tentando di eseguire.
L'OOM Killer deve selezionare il migliore processo(i) per uccidere. Il migliore qui si riferisce a quel processo che libererà la memoria massima dopo l'uccisione ed è anche il meno importante per il sistema.
L'obiettivo principale è eliminare il minor numero di processi che riduce al minimo il danno causato e allo stesso tempo massimizza la quantità di memoria liberata.
Per facilitare ciò, il kernel mantiene un oom_score per ciascuno dei processi. Puoi vedere il oom_score di ciascuno dei processi nel /proc filesystem sotto il pid directory.
$ cat /proc/10292/oom_score
Maggiore è il valore di oom_score di qualsiasi processo, maggiore è la sua probabilità di essere ucciso dall'OOM Killer in una situazione di memoria insufficiente.
Com'è il OOM_Score calcolato?
Nel set di patch di David, le vecchie euristiche badness() sono quasi del tutto
scomparse. Al contrario, il calcolo si trasforma in una semplice domanda su quale
percentuale della memoria disponibile viene utilizzata dal processo. Se
il sistema nel suo insieme ha poca memoria, la "memoria disponibile" è
la somma di tutta la RAM e dello spazio di scambio disponibile per il sistema.
Se invece la situazione OOM è causata dall'esaurimento della memoria consentita
a un determinato cpuset/gruppo di controllo, la "memoria disponibile" è la quantità totale
allocata a quel gruppo di controllo. Un calcolo simile viene effettuato
se sono stati superati i limiti imposti da una policy di memoria. In ogni caso,
l'utilizzo della memoria del processo è considerato la somma del suo set residente
(il numero di pagine RAM che sta utilizzando) e il suo utilizzo di swap.
Di conseguenza, questo calcolo produce un numero percentuale per dieci; un processo
che utilizza ogni byte della memoria a sua disposizione
avrà un punteggio di 1000, mentre un processo che non utilizza alcuna memoria riceverà
un punteggio pari a zero. Ci sono pochissime modifiche euristiche a questo punteggio,
ma il codice sottrae comunque una piccola quantità (30) dal punteggio dei
processi di proprietà della radice sulla nozione che siano leggermente superiori
prezioso rispetto ai processi di proprietà dell'utente.
Un'altra modifica che viene applicata consiste nell'aggiungere il valore memorizzato in ogni
variabile oom_score_adj di ogni processo, che può essere regolata tramite /proc.
Questa manopola consente di regolare l'attrattiva di ogni processo per
all'OOM killer nello spazio utente; impostarlo su -1000 disabiliterà completamente le uccisioni OOM
, mentre impostarlo su +1000 equivale a dipingere un
target di grandi dimensioni sul processo associato.
Riferimenti
Correlati:inconveniente quando si utilizza un chroot nell'elaborazione ad alte prestazioni?http://www.queryhome.com/15491/whats-happening-kernel-starting-killer-choose-which-process https://serverfault.com/a/571326