Killer OOM non funziona correttamente, porta a un sistema operativo bloccato

Per anni, il killer OOM del mio sistema operativo non funziona correttamente e porta a un sistema congelato.
Quando l'utilizzo della memoria è molto elevato, l'intero sistema tende a "congelare" (in effetti: diventando estremamente lento) per ore o addirittura giorni , invece di uccidere i processi per liberare la memoria.
Il massimo che ho registrato è di 7 giorni prima di dimettermi per eseguire un ripristino.
Quando sta per essere raggiunto OOM, lo iowait è molto alto (~ 70%), prima di diventare non misurabile.
Lo strumento: iotopha dimostrato che tutti i programmi leggono a una velocità effettiva molto elevata (per decine di MB / sec) dal mio disco rigido.
Cosa stanno leggendo quei programmi?
- La gerarchia di directory?
- Il codice eseguibile stesso?
Non esattamente ora.

[modificato] Al momento in cui ho scritto questo messaggio (nel 2017) stavo usando un ArchLinux aggiornato (4.9.27-1-lts), ma avevo già riscontrato il problema per anni.
Ho riscontrato lo stesso problema con varie distribuzioni Linux e diverse configurazioni hardware.
Attualmente (2019), sto usando un Debian 9.6 aggiornato (4.9.0) Ho 16 GB di RAM fisica, un SSD su cui è installato il mio sistema operativo e nessuna partizione di swap .

A causa della quantità di RAM che ho, non voglio abilitare una partizione di swap, dal momento che ritarderebbe solo l'apparizione del problema.
Inoltre, con gli SSD lo scambio troppo spesso potrebbe potenzialmente ridurre la durata del disco.
A proposito, ho già provato con e senza una partizione di swap, ha dimostrato di ritardare solo l'apparizione del problema, ma non essere la soluzione.

Per me il problema è causato dal fatto che Linux elimina i dati essenziali dalla cache , il che porta a un sistema congelato perché deve leggere tutto, ogni volta dal disco rigido.

Mi chiedo anche se Linux non lascerebbe cadere le code page eseguibili dei programmi in esecuzione, il che spiegherebbe perché i programmi che normalmente non leggono molti dati, si comportano in questo modo in questa situazione.

Ho provato diverse cose nella speranza di risolvere questo problema.
Uno era di impostare /proc/sys/vm/min_free_kbytessu 1000000(1 GB).
Poiché questo 1 GB dovrebbe rimanere libero, ho pensato che questa memoria sarebbe stata riservata da Linux per memorizzare nella cache dati importanti.
Ma non ha funzionato.

Inoltre, credo che utile aggiungere che, anche se può sembrare grande, in teoria, limitando la dimensione della memoria virtuale per la dimensione della memoria fisica, definendo /proc/sys/vm/overcommit_memoryper 2non è decentemente tecnicamente possibile nella mia situazione, perché il tipo di applicazioni che uso, richiedono più memoria virtuale di quella che usano effettivamente per alcuni motivi.
Secondo il file /proc/meminfo, il Commited_ASvalore è spesso superiore al doppio della RAM fisica sul mio sistema (16 GB, Commited_AS è spesso> 32 GB).

Ho riscontrato questo problema con il /proc/sys/vm/overcommit_memorysuo valore predefinito:, 0e per un po 'l'ho definito: 1perché ho preferito che i programmi venissero uccisi dal killer OOM piuttosto che comportarsi male perché non controllano i valori di ritorno di mallocquando le allocazioni sono rifiutate.

Quando stavo parlando di questo problema su IRC , ho incontrato altri utenti Linux che hanno riscontrato questo stesso problema, quindi immagino che molti utenti ne siano preoccupati.
Per me questo non è accettabile poiché anche Windows gestisce meglio l'utilizzo di memoria elevata.

Se hai bisogno di maggiori informazioni, invia un suggerimento, per favore dimmelo.

Documentazione:
https://en.wikipedia.org/wiki/Thrashing_%28computer_science%29
https://en.wikipedia.org/wiki/Memory_overcommitment
https://www.kernel.org/doc/Documentation/sysctl/vm. txt
https://www.kernel.org/doc/Documentation/vm/overcommit-accounting
https://lwn.net/Articles/317814/

Ne parlano:
perché il killer di memoria di Linux (OOM) non viene eseguito automaticamente, ma funziona su sysrq-key?
Perché a volte OOM-killer non riesce a uccidere i maiali delle risorse?
Precaricamento di OOM Killer
È possibile attivare OOM-killer in caso di scambio forzato?
Come evitare la latenza elevata vicino alla situazione OOM?
https://lwn.net/Articles/104179/
https://bbs.archlinux.org/viewtopic.php?id=233843

— M89
fonte

Penso che questo sia quello che dovresti aspettarti, se stai battendo, ma non ti stai davvero avvicinando al "usato" al 100%, cioè c'è un uso eccessivo della memoria che è supportato da file, conteggiato come "buff / cache". (Ugh, questo fraseggio presuppone che le allocazioni di tmpfs siano insignificanti, in quanto vengono visualizzate come "buff / cache", ma non possono essere inviate a un file system fisico). min_free_kbytesnon è pertinente, non è una riserva per le pagine memorizzate nella cache. AFAICT nessuno dei sistemi VM consente di riservare memoria specificamente per le pagine memorizzate nella cache, vale a dire limitando le allocazioni MAP_ANONYMOUS :(.

— sourcejedi

Da anni cerco una soluzione a questo problema esatto senza successo. Credo di aver notato per la prima volta il problema dopo aver sostituito il mio HDD con un SSD, il che mi ha comportato anche disabilitando del tutto lo scambio, ma non posso davvero garantire che non sia mai successo prima di questi cambiamenti, quindi potrebbe non essere correlato. Sono su Archlinux a proposito.

— brunocodutra,

Ho appena pubblicato sui forum Arch Linux su questo.

— Ignat Insarov,

@ dsstorefile1 Grazie, ci proverò. Ma come potrebbe innescare il killer OOM di sicuro quando il kernel in questa situazione non può farlo correttamente?

— M89,

Mi ha aiutato quando Chrome è riuscito a filtrare tutta la mia RAM ... (Anche se alla fine ho aggiunto anche una vera partizione di swap del disco e alla fine l'upgrade a una discreta quantità di RAM)

— Gert van den Berg

Risposte:

Ho trovato due spiegazioni (della stessa cosa) sul perché ~~kswapd0 non~~ lettura costante del disco avviene ben prima OOM-killer uccide il processo incriminato:

vedere la risposta e il commento di questa domanda di askubuntu SE
vedere la risposta e i commenti di David Schwartz di questa risposta su unix SE

Citerò qui il commento da 1. che mi ha davvero aperto gli occhi sul perché stavo ricevendo una lettura costante del disco mentre tutto era bloccato :

Ad esempio, si consideri un caso in cui lo swap è zero e il sistema sta quasi esaurendo la RAM. Il kernel prenderà memoria ad es. Da Firefox (può farlo perché Firefox sta eseguendo il codice eseguibile che è stato caricato dal disco - il codice può essere nuovamente caricato dal disco se necessario). Se Firefox ha bisogno di accedere nuovamente a quella RAM N secondi dopo, la CPU genera un "errore grave" che forza Linux a liberare un po 'di RAM (ad esempio prendere un po' di RAM da un altro processo), caricare i dati mancanti dal disco e quindi consentire a Firefox di continuare come solito. Questo è abbastanza simile al normale scambio e kswapd0 lo fa. - Mikko Rantalainen, 15 febbraio alle 13:08

Se qualcuno ha modo di disabilitare questo comportamento (magari ricompilare il kernel con quali opzioni? ), Per favore fatemi sapere al più presto! Molto apprezzato, grazie!

AGGIORNAMENTO: L'unico modo che ho trovato finora è attraverso l'applicazione di patch al kernel, e funziona per me con swap disabilitato (es. CONFIG_SWAP is not set) Ma non funziona per altri con swap abilitato sembra ; vedere la patch all'interno di questa domanda.

Si prega di rimuovere il testo che non è valido. Non contrassegnare le modifiche con "EDIT" nel testo. Sono evidenti dalla cronologia delle revisioni .

— Kusalananda

@Kusalananda Questo utente dovrebbe essere incoraggiato poiché è probabilmente quello che ha contribuito maggiormente.

— M89,

@Kusalananda Ho pensato che fosse importante tenerli in modo che gli altri potessero vedere cosa (altro) è stato provato e non ha funzionato. Forse UPDATEinvece di EDITsarebbe stato meglio?

@MarcusLinsner No, scusa, hai frainteso. Mostrando ciò che hai provato è quello che si fa quando si chiede una domanda. La risposta dovrebbe essere corretta per la domanda così come è attualmente posta. Voglio dire, una modifica chiede persino al lettore di ignorare le modifiche precedenti . Se uno è interessato a vedere la cronologia delle modifiche, puoi vederla qui .

— Kusalananda

Il memory.minparametro nel cgroups-v2controller di memoria dovrebbe aiutare.

Vale a dire, lasciatemi citare:

Protezione della memoria rigida. Se l'utilizzo della memoria di un cgroup rientra nel suo limite minimo effettivo, la memoria del cgroup non verrà recuperata in nessuna condizione. Se non è disponibile memoria recuperabile non protetta, viene richiamato Killer OOM.

Fonte: https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html

— Vladimir Nikishkin
fonte

Potresti elaborare per favore? La tua risposta è un po 'breve nel rispondere alla domanda OP.

— Paradox,