Evita lo smontaggio delle applicazioni di memoria esaurita di Linux

Sto scoprendo che a volte la mia scatola di Linux esaurisce la memoria e inizia a distruggere processi casuali per affrontarla.

Sono curioso di sapere cosa fanno gli amministratori per evitarlo? L'unica vera soluzione per aumentare la quantità di memoria (aumentando il solo swap è di aiuto?), Oppure esistono modi migliori per configurare la scatola con il software per evitarlo? (vale a dire, quote o alcuni di questi?).

Per impostazione predefinita Linux ha un concetto un po 'cerebrale di gestione della memoria: ti consente di allocare più memoria di quella del tuo sistema, quindi spara casualmente un processo in testa 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 argomenti sul fatto che sia una cosa buona o cattiva).

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

1. Disabilita OOM Killer (Inserisci vm.oom-kill = 0in /etc/sysctl.conf)
2. Disabilita overcommit memoria (Inserisci vm.overcommit_memory = 2in /etc/sysctl.conf)
   Nota che questo è un valore temporaneo: 0 = "stima se abbiamo abbastanza RAM", 1 = "Dì sempre di si", 2 = "dì no se non lo facciamo avere 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 quell'errore).

Riavviare il computer per ricaricarlo /etc/sysctl.confo utilizzare il procfile system per abilitarlo immediatamente, senza riavviare:

echo 2 > /proc/sys/vm/overcommit_memory 

È possibile disabilitare l'overcommit, consultare http://www.mjmwired.net/kernel/Documentation/sysctl/vm.txt#514

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

Un server che ha riscontrato abbastanza regolarmente errori OOM (memoria esaurita), quindi oltre all'opzione sysctl del gestore VM (memoria virtuale) nei kernel Linux, questa non è una buona cosa.

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

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

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

Nozioni di base sull'esame del consumo di memoria, incluso l'utilizzo freee top, ordinati per utilizzo della memoria, come le due valutazioni rapide più comuni dei modelli di utilizzo della memoria. Quindi assicurati di capire almeno il significato di ciascun campo nell'output di quei comandi.

Senza specifiche di applicazioni (ad es. Database, server dei servizi di rete, elaborazione video in tempo reale) e utilizzo del server (pochi utenti esperti, 100-1000 secondi di connessioni utente / client), non riesco a pensare a nessuna raccomandazione generale in merito alla gestione di il problema OOM.

L'aumento della quantità di memoria fisica potrebbe non essere una risposta efficace in tutte le circostanze.

Un modo per verificarlo è il comando "in cima". In particolare queste due linee.

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 che regolassimo overcommit_memory da 50 a 90, vedevamo un comportamento con vmcom che funzionava ben oltre 50G, oom-killer che faceva saltare i processi ogni pochi secondi e il carico continuava a rimbalzare radicalmente a causa dei processi figlio di NFSd che venivano fatti saltare e ricreato continuamente.

Recentemente abbiamo duplicato i casi in cui i terminal server Linux multiutente commettono in modo massiccio l'allocazione della memoria virtuale, ma pochissime delle pagine richieste vengono effettivamente consumate.

Sebbene non sia consigliabile seguire questa rotta esatta, abbiamo modificato la memoria di overcommit dai valori predefiniti da 50 a 90, il che ha attenuato alcuni dei problemi. Alla fine abbiamo dovuto spostare tutti gli utenti su un altro Terminal Server e riavviarlo per vedere tutti i vantaggi.

È possibile utilizzare ulimit per ridurre la quantità di memoria che un processo è autorizzato a rivendicare prima che venga interrotto. È molto utile se il tuo problema è uno o alcuni processi di fuga che causano l'arresto anomalo del server.

Se il tuo problema è che semplicemente 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 le 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

Ho avuto un problema simile relativo a questo bug e la soluzione era usare il kernel più vecchio / più recente (fisso).

Tuttavia, al momento non riuscivo a riavviare il mio computer, quindi una sorta di brutta soluzione era accedere come root e cancellare le cache di sistema con questo comando:

echo 3 > /proc/sys/vm/drop_caches

@ voretaq7 linux non ha un concetto cerebrale di gestione della memoria danneggiato, per impostazione predefinita vm.overcommit_ratio è 0,

0       -   Heuristic overcommit handling. Obvious overcommits of
            address space are refused. Used for a typical system. It
            ensures a seriously wild allocation fails while allowing
            overcommit to reduce swap usage.  root is allowed to
            allocate slightly more memory in this mode. This is the
            default.

In questo modo, se si dispone di 4 GB di RAM e si tenta di allocare 4,2 GB con malloc di memoria virtuale, l'allocazione fallirà.

Con vm.overcommit_ratio = 1

            1    -   Always overcommit. Appropriate for some scientific
            applications. Classic example is code using sparse arrays
            and just relying on the virtual memory consisting almost
            entirely of zero pages.

Con vm.overcommit_ratio = 2

           2    -   Don't overcommit. The total address space commit
            for the system is not permitted to exceed swap + a
            configurable percentage (default is 50) of physical RAM.
            Depending on the percentage you use, in most situations
            this means a process will not be killed while accessing
            pages but will receive errors on memory allocation as
            appropriate.

            Useful for applications that want to guarantee their
            memory allocations will be available in the future
            without having to initialize every page.

Quindi, per impostazione predefinita, Linux non si sovraccarica, se la tua applicazione ha più memoria di quella che hai, forse il tuo codice è difettoso