Il killer OOM non funziona?

41

Per quello che ho capito, quando il sistema è vicino a non avere memoria libera, il kernel dovrebbe iniziare a terminare i processi per recuperare memoria. Ma nel mio sistema questo non accade affatto.

Supponiamo uno script semplice che alloca solo molta più memoria di quella disponibile nel sistema (un array con milioni di stringhe, per esempio). Se eseguo uno script come questo (come un normale utente), ottiene solo tutta la memoria fino a quando il sistema non si blocca completamente (funziona solo SysRQ REISUB).

La parte strana qui è che quando il computer si blocca, il led del disco rigido si accende e rimane così fino al riavvio del computer, sia se ho una partizione di swap montata o no!

Quindi le mie domande sono:

Questo comportamento è normale? È strano che un'applicazione eseguita come un normale utente possa semplicemente arrestare il sistema in questo modo ...
C'è un modo in cui posso fare in modo che Ubuntu uccida automaticamente quelle applicazioni quando ottengono troppa (o più) memoria?

Informazioni aggiuntive

Ubuntu 12.04.3
Kernel 3.5.0-44

RAM: ~ 3,7 GB da 4 GB (condivisa con la scheda grafica). *

$ tail -n+1 /proc/sys/vm/overcommit_*
==> /proc/sys/vm/overcommit_memory <==
0

==> /proc/sys/vm/overcommit_ratio <==
50

$ cat /proc/swaps
Filename                Type        Size    Used    Priority
/dev/dm-1                               partition   4194300 344696  -1

kernel

— Salem
fonte

Non sono sicuro del perché non funzioni. Prova ad tail -n+1 /proc/sys/vm/overcommit_*aggiungere l'output. Vedi anche qui: Come configuro oom-killer

— kiri

Cosa sta succedendo con il tuo spazio di swap? Puoi pubblicare un output di vmstat come #vmstat 1 100 o qualcosa del genere? e mostraci anche cat / etc / fstab Quello che dovrebbe succedere è con un certo uso della memoria, dovresti iniziare a scrivere per scambiare. I processi di uccisione non dovrebbero avvenire fino a quando la memoria e lo spazio di scambio non saranno "pieni".

— j0h

prova anche #swapon -a

— j0h

@ j0h Con swap sembra funzionare bene (dopo qualche tempo il processo si è bloccato con qualcosa di simile Allocation failed). Ma senza scambio, congela semplicemente il computer. Dovrebbe funzionare in questo modo (uccidere solo quando si usa lo swap)?

— Salem,

2

Con SysRq puoi anche invocare OOM (SysRq + F iirc)

— Lekensteyn

36

Dalla documentazione ufficiale/proc/sys/vm/* :

oom_kill_allocating_task

Ciò abilita o disabilita l'uccisione dell'attività di attivazione OOM in situazioni di memoria insufficiente.

Se impostato su zero, il killer OOM eseguirà la scansione dell'intero elenco di attività e selezionerà un'attività in base all'euristica da uccidere. Questo normalmente seleziona un'attività di hogging di memoria non valida che libera una grande quantità di memoria quando viene uccisa.

Se impostato su un valore diverso da zero, il killer OOM uccide semplicemente l'attività che ha attivato la condizione di memoria insufficiente. Ciò evita la costosa scansione dell'elenco delle attività.

Se viene selezionato panic_on_oom, ha la precedenza su qualsiasi valore venga utilizzato in oom_kill_allocating_task.

Il valore predefinito è 0.

Per riassumere, quando si imposta oom_kill_allocating_tasksu 1, invece di eseguire la scansione del sistema alla ricerca di processi da eliminare, che è un'attività costosa e lenta, il kernel ucciderà semplicemente il processo che ha causato l'esaurimento della memoria del sistema.

Dalle mie esperienze personali, quando viene attivato un OOM, il kernel non ha più "forza" sufficiente per eseguire tale scansione, rendendo il sistema totalmente inutilizzabile.

Inoltre, sarebbe più ovvio semplicemente uccidere l'attività che ha causato il problema, quindi non riesco a capire perché sia impostato di 0default.

Per il test, puoi semplicemente scrivere nello pseudo-file corretto in /proc/sys/vm/, che verrà annullato al prossimo riavvio:

echo 1 | sudo tee /proc/sys/vm/oom_kill_allocating_task

Per una correzione permanente, scrivere quanto segue in /etc/sysctl.confo in un nuovo file in /etc/sysctl.d/, con .confun'estensione ( /etc/sysctl.d/local.confad esempio):

vm.oom_kill_allocating_task = 1

— Teresa e Junior
fonte

2

È sempre stato impostato su 0 in Ubuntu? Perché ricordo che uccideva automaticamente, ma da alcune versioni ha smesso di farlo.

— skerit,

1

@skerit Questo non lo so davvero, ma era impostato su 0 nei kernel che ho usato nel 2010 (Debian, Liquorix e GRML).

— Teresa e Junior,

"Inoltre, sarebbe più ovvio semplicemente uccidere l'attività che ha causato il problema, quindi non riesco a capire perché sia impostato di 0default." - perché il processo che ha richiesto memoria non è necessariamente quello che ha "causato il problema". Se il processo A ha il 99% della memoria del sistema, ma il processo B, che utilizza lo 0,9%, sembra essere quello che innesca il killer OOM per sfortuna, B non ha "causato il problema" e non ha senso uccidere B. Avere questo dato che la politica rischia di uccidere per caso processi a memoria insufficiente totalmente privi di problemi a causa dell'utilizzo della memoria in fuga di un processo diverso .

— Mark Amery,

1

@MarkAmery Il vero problema è che Linux, invece di uccidere il processo necessario, inizia a battere come un ritardo, anche se vm.admin_reserve_kbytesviene aumentato, per esempio, a 128 MB . L'impostazione vm.oom_kill_allocating_task = 1sembra alleviare il problema, non lo risolve davvero (e Ubuntu si occupa già di default delle bombe a forcella).

— Teresa e Junior,

1

Forse più elegantesudo sysctl -w vm.oom_kill_allocating_task=1

— Pablo Un

9

Aggiornamento: il bug è stato corretto.

La risposta di Teresa è sufficiente per risolvere il problema ed è buona.

Inoltre, ho presentato una segnalazione di bug perché si tratta sicuramente di un comportamento non corretto.

— int_ua
fonte

Non so perché sei stato sottoposto a downgrade, ma a me sembra anche un bug del kernel. Oggi ho bloccato un grosso server universitario con esso e ho ucciso alcuni processi in esecuzione per settimane ... Grazie per aver archiviato la segnalazione di bug!

— shapecatcher,

7

Potrebbe essere stato risolto nel 2014, nel 2018 (e 18.04) il killer OOM non sta ancora facendo nulla.

— skerit,

0

Puoi provare earlyoom , un killer OOM che opera nello spazio utente e cerca di uccidere il processo più grande in una situazione OOM.

— QWR
fonte

-1

Prima di tutto consiglio l'aggiornamento alla 13.10 (installazione pulita, salvataggio dei dati).

Se non vuoi aggiornare, modifica vm.swappiness su 10 e se riscontri problemi con il tuo ram installa zRAM.

— Brask
fonte

2

Non sono stato io a sottovalutarti, ma generalmente l'abbassamento vm.swappinessfa più male che bene, ancora di più su sistemi che soffrono di problemi di memoria insufficiente.

— Teresa e Junior,

Non quando comprimi prima il ram e quindi eviti l'uso del disco che è molto più lento e può bloccare il computer.

— Brask,

In teoria, zRAM è una cosa carina, ma ha fame di CPU e generalmente non vale il costo. La memoria è generalmente molto più economica dell'elettricità. E, su un laptop, dove l'aggiornamento della RAM è più costoso, l'utilizzo della CPU è per lo più indesiderabile.

— Teresa e Junior,

Quello che sta chiedendo è di avere un sistema zRAM più stabile e il cambio di swappiness farà sì che il suo sistema utilizzi più risorse CPU sì, ma ciò che è limitato atm e con errori è la memoria, vuole risolvere il problema non una lezione di teoria di cosa succede quando si installa zRAM.

— Brask,

È chiaro dalla sua domanda che potrebbe scrivere una sceneggiatura impropria che mangia più di quanto dovrebbe (e l'ho già fatto da solo). In una situazione come questa, puoi guardare lo script che acquisisce gigabyte di RAM in pochi secondi e zRAM non verrà in soccorso, poiché lo script non sarà mai abbastanza soddisfatto.

— Teresa e Junior,