Come posso evitare che Linux si blocchi quando non ho memoria?

25

Oggi ho (accidentalmente) eseguito un programma sul mio box Linux che ha rapidamente utilizzato molta memoria. Il mio sistema si è bloccato, non ha risposto e quindi non sono stato in grado di uccidere l'autore del reato.

Come posso impedirlo in futuro? Non può almeno mantenere un core reattivo o qualcosa in esecuzione?

linux oom

— johv
fonte

Duplica del sistema che si blocca quando si esaurisce la memoria , ed è un noto bug

— Dan Dascalescu,

15

Scommetto che il sistema in realtà non si "congela" (nel senso che il kernel si blocca), ma piuttosto non risponde. È probabile che si stesse scambiando molto duramente, causando un calo delle prestazioni interattive e del throughput del sistema.

Si potrebbe spegnere swap, ma che cambia solo il problema da scarse prestazioni ai processi OOM-ucciso (e tutto il divertimento che le cause), insieme a una diminuzione delle prestazioni a causa di cache su disco meno disponibili.

In alternativa, potresti utilizzare i limiti delle risorse per processo (comunemente indicati come rlimite / o ulimit) per rimuovere la possibilità che un singolo processo prenda una quantità ridicola di memoria e causi lo scambio, ma ciò ti spinge semplicemente in un territorio divertente con processi che muoiono a momenti inopportuni perché volevano un po 'più di memoria di quanto il sistema fosse disposto a dare loro.

Se sapessi che avresti fatto qualcosa che avrebbe potuto causare un massiccio utilizzo della memoria, probabilmente avresti potuto scrivere un programma wrapper che eseguiva una mlockall()e quindi eseguiva la tua shell; lo manterrebbe in memoria e sarebbe la cosa più vicina a "mantenere un core reattivo" che probabilmente otterrai (perché non è che la CPU è sottoutilizzata, questo è il problema).

Personalmente, sottoscrivo il metodo di controllo delle risorse "non fare cose stupide". Se hai root, puoi fare tutti i tipi di danni a un sistema, e quindi fare qualsiasi cosa di cui non conosci i probabili risultati è un'attività rischiosa.

— womble
fonte

2

Sfortunatamente, "non fare cose stupide" non aiuta gli utenti che eseguono applicazioni di memorizzazione della memoria come Chrome (vedere i problemi 134612 , 393395 ).

— Dan Dascalescu,

1

@DanDascalescu E non è sempre ovvio che stai facendo qualcosa di stupido. La mia macchina si è bloccata l'altro giorno perché ho cambiato un "UNION" in una (complicata) query SQLite in "UNION ALL".

— Michael,

I programmi con buggy noti possono (e dovrebbero) essere eseguiti in una configurazione a risorse limitate - ulimito persino cgroups al giorno d'oggi, se sei un giovane alla moda, fa abbastanza bene il lavoro. Se stai apportando modifiche alle query in produzione senza convalidare i loro effetti in un ambiente non critico, questo è il tuo problema di causa principale.

— womble

8

Come menzionato sopra nel commento di Tronic, è possibile chiamare OOM-killer (memoria esaurita) direttamente dalla combinazione di tasti SysRq- F.

SysRqil tasto viene solitamente combinato con il PrtSctasto delle tastiere.

OOM-killer uccide alcuni processi e il sistema diventa di nuovo reattivo. L'accesso diretto a OOM-killer potrebbe non essere abilitato per impostazione predefinita, per favore controlla questa domanda per scoprire come controllarne lo stato e / o abilitarlo.

PS: Questo mi ha aiutato molto. Sono d'accordo con l'opinione che questo è il consiglio più utile su quel problema se causato da Chrome o da qualsiasi software avido di memoria. Ma devi tenere a mente che OOM-killer potrebbe uccidere alcuni processi davvero importanti, usalo attentamente.

— Arkemlar
fonte

1

Questo è un bug noto dal 2007 - vedi Blocco del sistema in caso di utilizzo elevato della memoria .

In questa situazione, Windows visualizza una finestra di dialogo che avvisa l'utente di chiudere una o più applicazioni.

— Dan Dascalescu
fonte

0

Se hai voglia di ricompilare il kernel, puoi provare la patch dalla EDITsezione di questa domanda: /programming//q/52067753/10239615
Non sfrutta le Active(file)pagine durante l'alta pressione della memoria e quindi consente OOM-killer innescarsi quasi istantaneamente perché il kernel non ha più bisogno di passare minuti di rilettura costante da disco delle tabelle di codici eseguibili di ogni processo che causano un sistema operativo bloccato.

-1

Questo è qualcosa di particolarmente difficile da prevenire. È perché il kernel inizia a scambiarsi. Una soluzione è disattivare lo swap. Quando il sistema esaurisce la memoria, anziché iniziare a scambiare, il kernel ucciderà alcuni processi; di solito raccoglie il processo corretto per uccidere, ma è comunque meglio uccidere un processo casuale piuttosto che avere un sistema che non risponde.

Questa può essere una soluzione particolarmente buona per i server, perché i server spesso hanno abbastanza RAM e quando iniziano a utilizzare lo spazio di swap significa comunque che qualcosa non va. Tuttavia, i desktop di solito hanno bisogno dello spazio di scambio, quindi penso che non ci sia una buona soluzione per i desktop. Spesso disattivo lo spazio di scambio nei server, specialmente quando si sospetta una perdita di memoria.

— Antonis Christofides
fonte

4

Disattivare lo scambio su qualsiasi sistema è una cattiva idea, perché non consente di scambiare le pagine inutilizzate e lo spazio libero utilizzato per la cache del disco. Questo è particolarmente vero quando c'è una perdita di memoria.

— womble

2

E con lo swap disattivato, il sistema può ancora rallentare a causa del paging. Sarà semplicemente impaginare le pagine pulite follemente anziché quelle sporche. (Dato che, senza scambio, non potrà mai sfrattare una pagina sporca, dovrà sempre sfrattare quelle pulite.)

— David Schwartz,

Ho un server che ha una perdita di memoria. La prima volta che è successo, ho dovuto premere il pulsante di ripristino, perché il server non ha risposto. Ma ora che ho disattivato lo scambio, il server uccide il figlio apache se diventa troppo grande (è una protezione oltre a MaxRequestsPerChild). Il risultato è che il server funziona senza problemi. Non ha comunque molte pagine inutilizzate, e certamente non sta impaginando follemente pagine pulite.

— Antonis Christofides,

@AntonisChristofides: Non sono sicuro di cosa pensi che sia la lezione da asporto. La tua soluzione è sicuramente negativa perché ostacola le prestazioni a causa dell'incapacità di eliminare dalla memoria fisica pagine sporche a cui si accede raramente, non ha risolto il problema di fondo e si corre il rischio che il killer OOM possa interrompere un processo critico. Ti è capitato di non incontrare il pericolo particolare di cui stavo avvertendo, ma sei ancora a rischio perché non hai swap.

— David Schwartz,

8

Con o senza scambio, si blocca ancora prima che il killer OOM venga eseguito automaticamente. Questo è davvero un bug del kernel che dovrebbe essere corretto (ad esempio, eseguire OOM killer prima, prima di eliminare tutta la cache del disco). Sfortunatamente gli sviluppatori del kernel e molte altre persone non riescono a vedere il problema. Suggerimenti comuni come disabilitare / abilitare lo scambio, acquistare più RAM, eseguire meno processi, impostare limiti ecc. Non affrontano il problema di fondo che la scarsa gestione della memoria del kernel fa schifo le palle di cammello. Nel frattempo, suggerisco di eseguire manualmente il killer OOM (SysRq-F) quando il sistema si blocca in quanto ciò lo farà recuperare più velocemente.

— Tronic,