Il motivo per cui l'OOM-killer non viene chiamato automaticamente è perché il sistema, sebbene completamente rallentato e non risponde già quando quasi vicino all'esaurimento della memoria y, non ha effettivamente raggiunto la situazione di memoria insufficiente.
Semplificato eccessivamente, la ram quasi piena contiene 3 tipi di dati:
- dati del kernel, questo è essenziale
- pagine di dati di processo essenziali (ad es. qualsiasi dato creato dal processo solo nella ram)
- pagine di dati di processo non essenziali (ad esempio dati come il codice degli eseguibili, per i quali esiste una copia su disco/nel filesystem, e che pur essendo attualmente mappati in memoria potrebbero essere "riletti" dal disco al momento dell'utilizzo )
In una situazione affamata di memoria, il kernel Linux, per quanto ne so, è kswapd0 Il thread del kernel, per prevenire la perdita di dati e la perdita di funzionalità, non può eliminare 1. e 2. , ma è libero di rimuovere almeno temporaneamente i dati dei file mappati nella memoria dalla RAM, ovvero i processi dei moduli che non sono attualmente in esecuzione.
Mentre questo è un comportamento che comporta il disk-thrashing, per buttare via costantemente i dati e rileggerli dal disco, può essere visto come utile in quanto evita, o almeno pospone la necessaria rimozione/uccisione di un processo e la liberazione-ma-anche- perdendo la sua memoria, ha un alto prezzo:prestazioni.
[load pages from disk to ram with code of executable of process 1]
[ run process 1 ]
[evict pages with binary of process 1 from ram]
[load pages from disk to ram with code of executable of process 2]
[ run process 2 ]
[evict pages with binary of process 2 from ram]
[load pages from disk to ram with code of executable of process 3]
[ run process 3 ]
[evict pages with binary of process 3 from ram]
....
[load pages from disk to ram with code of executable of process 1]
[ run process 1 ]
[evict pages with binary of process 1 from ram]
è chiaramente IO costoso ed è probabile che il sistema non risponda, anche se tecnicamente non si è ancora esaurito completamente di memoria.
Dal punto di vista dell'utente, tuttavia, sembra che essere bloccati/congelati e l'interfaccia utente che non risponde potrebbe non essere davvero preferibile, rispetto alla semplice interruzione del processo (ad esempio di una scheda del browser, il cui utilizzo della memoria potrebbe essere stato la causa principale/colpevole di iniziare con.)
È qui che la domanda indicava che il trigger del tasto Magic SysRq per avviare manualmente OOM sembra ottimo, poiché Magic SysRq è meno influenzato dalla mancata risposta del sistema.
Mentre potrebbero esserci casi d'uso in cui è importante preservare i processi (performance ) costi, per un desktop, è probabile che gli utenti preferirebbero l'OOM-killer rispetto all'interfaccia utente bloccata. C'è una patch che afferma di esentare dalla memoria i file supportati da fs mappati puliti in tale situazione in questa risposta su StackOverflow.
Potresti guardare il file /sys/fs/cgroup/memory/memory.oom_control, durante uno stress test.
o
Potresti guardare la data dell'ultima modifica, per vedere se è stata modificata nel periodo dell'ultimo blocco. Questo ti dirà se stava tentando di fare il suo lavoro.
under_oom 0
Questo è il tuo problema:
under_oom 0 or 1 (if 1, the memory cgroup is under OOM, tasks may
be stopped.)
Se impostato a 1, significa che è sotto il controllo di oom. Abilitato.
Se impostato su 0, in questo modo non è sotto il controllo di oom. Disabilitato.