out-of-memory killer: nohang e altri

Vi è capitato di aprire decine di schede (TAB) in Firefox o Chrome, e ad un certo punto il sistema è diventato instabile e quindi inutilizzabile? Ciò potrebbe essere stato causato dal termine dello spazio RAM disponibile.

Il problema è che il sistema inizia a killare, ossia chiudere, i processi che occupano tanta RAM, ad esempio alcune schede del browser, tuttavia il sistema rimane instabile anche dopo parecchi minuti.
Questo succede perchè le condizioni di esaurimento della memoria (out-of-memory, OOM) possono causare freeze, livelock, cancellazione della cache ed eliminazione dei processi (tramite l’invio di SIGKILL) invece di provare a chiuderli in maniera più soft: tramite l’invio di SIGTERM o altre azioni correttive.

Artem S. Tashkinov ad agosto (2019) invia il messaggio “Let’s talk about the elephant in the room – the Linux kernel’s inability to gracefully handle low memory pressure” alla mailing list LKML.org in cui espone questo problema, ecco un estratto:

Ciao,
C’è questo bug che infastidisce molte persone già da molti anni e che è riproducibile in pochi minuti usando il kernel più recente 5.2.6.
Tutti i parametri del kernel sono quelli delle impostazioni predefinite.

Questi sono i passi per riprodurre l’anomalia:
1) Avvio con mem=4G
2) Disabilita lo swap per rendere tutto più veloce (sudo swapoff -a)
3) Avviare un browser ad es. Chrome/Chromium o/e Firefox
4) Inizia ad aprire svariate schede e notare come la RAM libera diminuisce.

Ad un certo punto si raggiunge una situazione nella quale quando si apre una nuova scheda che richiede più RAM di quella disponibile, il sistema si blocca. A malapena si riesce a muovere il puntatore del mouse. Il LED del disco lampeggerà incessantemente (non sono del tutto sicuro del perché). Non si riesce più ad aprire nuove applicazioni o chiudere quelle già in esecuzione.

Questa instabilità può continuare per minuti o anche di più. Penso non sia così che il sistema dovrebbe comportarsi in questa situazione. Credo
debba essere fatto qualcosa a riguardo, per evitare questo stallo.

Sono quasi sicuro che, con la modifica di alcuni parametri di sysctl, la situazione si potrebbe evitare ma qualcosa mi dice che ciò potrebbe essere reso disponibile per tutti e le modifiche diventare predefinite.“

Esistono alcuni progetti e soluzioni per sopperire a questo problema per esempio usare uno degli OOM killer disponibili in userspace:

earlyoom: Questo è un programma di prevenzione OOM semplice, stabile e minuscolo scritto in C (la scelta migliore per server integrati e vecchi). Ha dipendenze minime e può funzionare con kernel più vecchi. https://github.com/rfjakob/earlyoom

oomd: Questo è un killer OOM dello spazio utente per sistemi Linux scritto in C ++ e sviluppato da Facebook. Questa è la scelta migliore per l’uso in grandi data center. Ha bisogno di Linux 4.20+. https://github.com/facebookincubator/oomd

low-memory-monitor: Un progetto nato da pochi mesi. https://gitlab.freedesktop.org/hadess/low-memory-monitor/

nohang: nohang è nuovo ed è una versione potenziata di earlyoom e ha molte funzioni utili. https://github.com/hakavlad/nohang

nohang è un demone configurabile con lo scopo di prevenire l’esaurimento della memoria (OOM) e mantenere la reattività del sistema in condizioni di memoria insufficiente.
Esso permette l’invio del segnale SIGTERM, che è l’azione correttiva predefinita. Se il target non risponde a SIGTERM, dopo ulteriore riduzione della memoria viene dato un SIGKILL.
E’ possibile personalizzazione della selezione del target: incidere direttamente sui processi, che rubano più RAM, attraverso l’abbinamento dei loro nomi, cgroups, percorsi reali exe, dintorni, cmdline ed euid con espressioni regolari.