Impedire il congelamento di Ubuntu, anche se la memoria del sistema è insufficiente

A volte lavoro con enormi quantità di dati che voglio conservare in memoria per l'elaborazione. A volte calcolo erroneamente la quantità di memoria prodotta dal mio programma o un debugger moltiplica l'utilizzo della memoria per un fattore che supera la mia memoria disponibile.

Ogni volta che avvio un processo affamato di memoria, questo è quello che mi aspetterei da un sistema operativo sano: prova a consumare tutta la memoria libera, quindi chiedi ad altri processi non essenziali di rinunciare alla memoria di cui non hanno bisogno, quindi scrivi per scambiare.

Ecco cosa fa Ubuntu per me: mangia tutta la memoria libera, quindi chiedi al sistema operativo di scambiare tutti i servizi essenziali (sessione gnome, terminale, tastiera), quindi congela e attendi che stacchi la spina.

Due domande:

1. Come può un sistema operativo supporre che qualcosa potrebbe essere così importante che è ok smettere di ascoltare l'input dell'utente?
2. Come posso dire a Ubuntu di non scambiare mai i servizi essenziali e di reagire sempre all'input dell'utente, anche se qualche stupido processo cerca di consumare più risorse di quelle fornite dal sistema.

Non ho ancora una soluzione al problema, ma posso offrire due soluzioni alternative che potrebbero interessare gli altri:

1) earlyoom

Questo è un servizio che controlla l'utilizzo della memoria e uccide il processo che consuma più memoria quando viene raggiunta una certa soglia (vedi anche questa e questa domanda riguardo al killer OOM nel kernel di Linux)

L'ho provato con un processo demo che richiede indefinitamente memoria in piccoli pezzi. Ecco la mia prima impressione: quando avvio il processo canaglia, si esaurisce rapidamente tutta la mia RAM. Quindi inizia lo scambio, il sistema non risponde. Pochi secondi dopo il sistema è di nuovo online. Il registro di earlyoom mostra che ha interrotto il processo di consumo della memoria dopo che l'utilizzo della memoria e dello scambio ha raggiunto il 90%.

C'è ancora il fastidioso ritardo quando inizia lo scambio e dopo che il processo è stato interrotto, alcune parti di altri processi di solito rimangono in scambio fino a quando non vengono richieste, ma è un inizio.

2) basta disabilitare lo scambio

So che questo è un argomento controverso , ma ai fini dei sistemi desktop e in particolare delle macchine di sviluppo in cui può succedere di tanto in tanto che un processo tenti di consumare tutta la tua memoria, ha senso: senza scambio, il killer OOM funziona come inteso. Quando esaurisci la memoria, trova il processo migliore per uccidere e sbarazzarsene. Nessun ritardo, nessun ritardo.

È possibile disabilitare lo scambio per la sessione corrente con sudo swapoff -ao rendere permanente la modifica .

La soluzione corretta per il problema sarebbe ovviamente che il sistema rimane reattivo quando la memoria principale è esaurita e inizia a scambiare memoria come se non ci fosse un domani, ma ciò non sembra accadere presto.

Prova una delle due cose:

1) modificare l'impostazione di swappiness dalla sua impostazione predefinita di 60, a 10, ovvero: aggiungere vm.swappiness = 10 a /etc/sysctl.conf (nel terminale, digitare sudo gedit /etc/sysctl.conf), quindi riavviare il sistema. Cerca qui swapiness per maggiori informazioni a riguardo.

2) Se lo swapiness non aiuta ... anche se potresti non voler ... aumentare le dimensioni del tuo file di swap a 1,5x16G e vedere se questo aiuta.

Tienimi aggiornato. Saluti, Al

Ho risolto un problema simile. Non so se la mia esperienza potrebbe essere adatta a te ...

Recentemente ho pubblicato una guida su come installare Linux su dispositivi LVM loopback che si avviano da USB (quindi senza dover installare grub sul disco interno, lasciandolo come originale). Ecco la guida: https://github.com/DareDevil73/linux-on-loopback-usb .

Poi sono caduto nel problema del congelamento con un carico di memoria elevato e ho osservato un utilizzo anormale dello spazio di swap (tutta la RAM consumata e l'utilizzo di swap vicino a zero). Ovviamente la partizione di swap LVM era montata e funzionava correttamente, ma non so perché il kernel non la usasse come previsto.

Ho provato una soluzione alternativa. Ho creato un file di loopback di swap (non LVM) e il blocco è sparito. Ora il file di scambio viene utilizzato come sarebbe e il sistema operativo non si blocca mai!

Si prega di consultare https://github.com/DareDevil73/linux-on-loopback-usb#nown-issues per ottenere informazioni più approfondite.