Per anni, il assassino di OOM del mio sistema operativo non funziona correttamente e provoca un blocco del sistema.
Quando l'utilizzo della memoria è molto elevato, l'intero sistema tende a "congelarsi" (infatti:diventando estremamente lento) per ore o anche giorni , invece di uccidere i processi per liberare la memoria.
Il massimo che ho registrato è di 7 giorni prima di rassegnarmi a eseguire un ripristino.
Quando l'OOM sta per essere raggiunto, iowait è molto molto alto (~ 70%), prima di diventare non misurabile.
Lo strumento:iotop ha dimostrato che tutti i programmi leggono a un throughput molto elevato (per decine di MB/sec) dal mio disco rigido.
Cosa stanno leggendo quei programmi ?
– La gerarchia delle directory ?
– Il codice eseguibile stesso ?
Non lo so 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 prima.
Ho riscontrato lo stesso problema con varie distribuzioni Linux e diverse configurazioni hardware.
Attualmente (2019), sto utilizzando una Debian 9.6 (4.9.0) aggiornata
ho 16 GB di ram fisica, un SSD su cui è installato il mio sistema operativo e non alcun swap partizione.
A causa della quantità di RAM che ho, non voglio abilitare una partizione di swap, poiché ritarderebbe solo l'apparizione del problema.
Inoltre, lo scambio troppo frequente degli SSD potrebbe potenzialmente ridurre la durata della disco.
A proposito, ho già provato con e senza una partizione di swap, ha dimostrato di ritardare solo l'apparizione del problema, ma non di essere la soluzione.
Per me il problema è causato dal fatto che Linux elimina i dati essenziali dalle cache , che porta a un sistema bloccato perché deve leggere tutto, ogni volta dal disco rigido.
Mi chiedo anche se Linux non eliminerebbe le codepage 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 impostare /proc/sys/vm/min_free_kbytes a 1000000 (1 GB).
Perché 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, ritengo utile aggiungere che anche se in teoria potrebbe suonare alla grande, limitando la dimensione della memoria virtuale alla dimensione della memoria fisica, definendo /proc/sys/vm/overcommit_memory a 2 non è tecnicamente possibile nella mia situazione, perché il tipo di applicazioni che utilizzo richiedono più memoria virtuale di quanta ne utilizzino effettivamente per alcuni motivi.
Secondo il file /proc/meminfo , il Commited_AS il valore è spesso superiore al doppio della ram fisica sul mio sistema (16 GB, Commited_AS è spesso> 32 GB).
Ho riscontrato questo problema con /proc/sys/vm/overcommit_memory al suo valore predefinito: , e da tempo l'ho definito:1 , perché preferivo che i programmi venissero uccisi dall'killer OOM piuttosto che comportarsi in modo sbagliato perché non controllano i valori di ritorno di malloc quando le assegnazioni vengono rifiutate.
Quando parlavo di questo problema su IRC , ho incontrato altri utenti Linux che hanno riscontrato lo stesso problema, quindi immagino che molti utenti siano preoccupati per questo problema.
Per me questo non è accettabile poiché anche Windows gestisce meglio l'utilizzo elevato della memoria.
Se hai bisogno di maggiori informazioni, hai 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é linux out-of-memory (OOM) killer non viene eseguito automaticamente, ma funziona su sysrq-key?
Perché OOM-killer a volte non riesce a uccidere i maiali di risorse?
/>Precaricamento di OOM Killer
È possibile attivare OOM-killer in caso di scambio forzato?
Come evitare una latenza elevata in prossimità di una situazione OOM?
https://lwn.net/Articles/104179 /
https://bbs.archlinux.org/viewtopic.php?id=233843
Risposta accettata:
Ho trovato due spiegazioni (della stessa cosa) sul perché kswapd0 lo fa la lettura costante del disco accade ben prima che OOM-killer uccida il processo incriminato:
- vedi la risposta e il commento di questa risposta di askubuntu SE
- vedi la risposta e i commenti di David Schwartz su questa risposta su unix SE
Citerò qui il commento di 1. che mi ha davvero aperto gli occhi sul motivo per cui stavo leggendo costantemente il disco mentre tutto era congelato:
Ad esempio, considera un caso in cui hai zero swap e il sistema sta
quasi esaurendo la RAM. Il kernel occuperà memoria, ad esempio da
Firefox (può farlo perché Firefox sta eseguendo codice eseguibile
che è stato caricato dal disco – il codice può essere caricato di nuovo dal disco
se necessario). Se Firefox ha quindi bisogno di accedere nuovamente a quella RAM N
secondi dopo, la CPU genera un "errore grave" che costringe Linux a
liberare un po' di RAM (ad es. prelevare un po' di RAM da un altro processo), caricare il
mancano i dati dal disco e quindi consenti a Firefox di continuare come al solito.
Questo è abbastanza simile al normale scambio e kswapd0 lo fa. – Mikko
Rantalainen 15 febbraio alle 13:08
Se qualcuno ha un modo su come disabilitare questo comportamento (forse ricompilare il kernel con quali opzioni?), per favore fatemelo sapere il prima possibile! Molto apprezzato, grazie!
AGGIORNAMENTO: L'unico modo che ho trovato finora è applicare la patch al kernel, e funziona per me con lo swap disabilitato (ad es. CONFIG_SWAP is not set ) ma sembra che non funzioni per altri con lo scambio abilitato; vedi la patch all'interno di questa domanda.