Evita lo smantellamento dell'applicazione Linux esaurita

Soluzione 1:

Per impostazione predefinita, Linux ha un concetto di gestione della memoria un po 'danneggiato dal cervello:ti consente di allocare più memoria di quella che ha il tuo sistema, quindi termina casualmente un processo quando si trova nei guai. (La semantica effettiva di ciò che viene ucciso è più complessa di così:Google "Linux OOM Killer" per molti dettagli e discussioni sul fatto che sia una cosa buona o cattiva).

Per ripristinare una parvenza di sanità mentale nella tua gestione della memoria:

1. Disabilita OOM Killer (metti vm.oom-kill = 0 in /etc/sysctl.conf)
2. Disabilita l'overcommit della memoria (metti vm.overcommit_memory = 2 in /etc/sysctl.conf)
   Nota che questo è un valore trinario:0 ="stima se abbiamo abbastanza RAM", 1 ="Dì sempre di sì", 2 ="dì di no se non abbiamo la memoria")

Queste impostazioni faranno in modo che Linux si comporti nel modo tradizionale (se un processo richiede più memoria di quella disponibile, malloc() fallirà e il processo che richiede la memoria dovrebbe far fronte a tale errore).

Riavvia la tua macchina per farla ricaricare /etc/sysctl.conf , o usa il proc file system da abilitare subito, senza riavviare:

echo 2 > /proc/sys/vm/overcommit_memory 

Soluzione 2:

Puoi disabilitare l'overcommit, vedi http://www.mjmwired.net/kernel/Documentation/sysctl/vm.txt#514

Soluzione 3:

La risposta breve, per un server, è acquistare e installare più RAM.

Un server che ha sperimentato abbastanza regolarmente OOM (Out-Of-Memory), quindi oltre all'opzione overcommit sysctl del gestore VM (memoria virtuale) nei kernel Linux, questa non è una buona cosa.

Aumentare la quantità di swap (memoria virtuale che è stata impaginata su disco dal gestore della memoria del kernel) aiuterà se i valori correnti sono bassi e l'utilizzo comporta molte attività ciascuna di tali grandi quantità di memoria, piuttosto che una o poche elabora ciascuno richiedendo una quantità enorme della memoria virtuale totale disponibile (RAM + swap).

Per molte applicazioni che allocano più di due volte (2x) la quantità di RAM come scambio fornisce un ritorno sul miglioramento decrescente. In alcune grandi simulazioni computazionali, questo può essere accettabile se il rallentamento della velocità è sopportabile.

Con RAM (ECC o meno) essere abbastanza conveniente per quantità modeste, ad es. 4-16 GB, devo ammettere che non ho riscontrato questo problema da molto tempo.

Le basi per osservare il consumo di memoria incluso l'uso di free e top , ordinati per utilizzo della memoria, come le due valutazioni rapide più comuni dei modelli di utilizzo della memoria. Quindi assicurati di comprendere almeno il significato di ogni campo nell'output di quei comandi.

Senza specifiche di applicazioni (ad esempio database, server di servizi di rete, elaborazione video in tempo reale) e utilizzo del server (pochi utenti esperti, 100-1000 di connessioni utente/client), non riesco a pensare a raccomandazioni generali in merito alla gestione il problema OOM.

Soluzione 4:

È possibile utilizzare ulimit per ridurre la quantità di memoria che un processo può richiedere prima di essere terminato. È molto utile se il tuo problema è uno o pochi processi in fuga che bloccano il tuo server.

Se il tuo problema è semplicemente che non hai abbastanza memoria per eseguire i servizi di cui hai bisogno, ci sono solo tre soluzioni:

1. Riduci la memoria utilizzata dai tuoi servizi limitando cache e simili

2. Crea un'area di scambio più ampia. Ti costerà in termini di prestazioni, ma può farti guadagnare un po' di tempo.

3. Acquista più memoria

Soluzione 5:

Aumentare la quantità di memoria fisica potrebbe non essere una risposta efficace in tutte le circostanze.

Un modo per verificarlo è il comando 'atop'. In particolare queste due righe.

Questo è fuori server quando era integro:

MEM | tot   23.7G | free   10.0G | cache   3.9G | buff  185.4M | slab  207.8M |
SWP | tot    5.7G | free    5.7G |              | vmcom  28.1G | vmlim  27.0G |

Quando funzionava male (e prima di regolare overcommit_memory da 50 a 90, vedremmo un comportamento con vmcom in esecuzione ben oltre i 50G, oom-killer che fa esplodere i processi ogni pochi secondi e il carico continua a rimbalzare radicalmente a causa dei processi figlio NFSd che vengono saltati e ricreato continuamente.

Di recente abbiamo duplicato casi in cui server terminal Linux multiutente sovraccaricano in modo massiccio l'allocazione di memoria virtuale, ma pochissime pagine richieste vengono effettivamente consumate.

Anche se non è consigliabile seguire esattamente questo percorso, abbiamo regolato l'overcommit-memory dal valore predefinito da 50 a 90, il che ha alleviato parte del problema. Alla fine abbiamo dovuto spostare tutti gli utenti su un altro terminal server e riavviare per vedere tutti i vantaggi.