È possibile far intervenire l'assassino OOM prima?


34

Cerco di ottimizzare il mio sistema di sviluppo per la massima affidabilità. Ho disabilitato lo scambio, perché per l'utilizzo della GUI la macchina non risponde in gran parte in modo tale da non essere più utilizzabile. Ciononostante, se le appicciche aggressioni divorano la memoria, alcuni meccanismi sembrano dare il via a quello sfruttando al massimo il costo della velocità. Non vi è alcuna operazione di sostituzione del disco rigido, ma anche il sistema non risponde. Quindi voglio lasciare che il killer OOM entri in azione prima che il sistema faccia uno sforzo speciale per guadagnare memoria. È possibile configurare il killer OOM affinché agisca se, ad esempio, c'è meno di 100 MB di memoria fisica libera?


2
Penso che il vero problema qui sia, non c'è abbastanza RAM per cominciare. Non userai lo swap a meno che non ci sia ram. Disattivando lo scambio ... finisci il ram e non hai dove cercarlo. Il che fa succedere cose brutte. Il tuo sistema sembra essere impostato male, e nessun aggiustamento lo risolverà.
Journeyman Geek

8
Non sono d'accordo Lo sviluppo e il "consumo energetico" spesso implicano un uso sperimentale. Ad esempio, quando si utilizza uno strumento di elaborazione delle immagini da riga di comando, non ci sono specifiche sulla quantità di memoria necessaria per l'operazione in relazione alle dimensioni dell'immagine. Quindi ho solo una prova. E non mi aspetto che renda inutile l'intera mia macchina. Per un singolo esperimento, potrei usare ulimit per mantenerlo sicuro, ma per il funzionamento dell'intero sistema con a volte un sacco di operazioni, il contenimento di un processo non è così utile, ma lo è sicuramente un'assicurazione sulla vita per l'intera macchina.
dronus,

1
Il fatto che il tuo sistema si fermi quando si utilizza lo scambio è sospetto. Il computer utilizza lo scambio perché la memoria è insufficiente. Lo scambio sta rallentando perché l'accesso al disco è lento. L'accesso al disco è lento a causa di ???. I suoi problemi fino in fondo. Non è solo che sei a corto di ariete. È che non puoi usare l'unico modo per mitarlo a causa di qualcos'altro.
Journeyman Geek

7
@JourneymanGeek, sei fuori nel campo a sinistra. I dischi sono lenti rispetto alla ram, punto, quindi lo scambio pesante fa sempre fermare il sistema. Naturalmente ha esaurito la memoria perché ha provato a eseguire un programma che utilizza molta memoria. La domanda è: cosa fare quando si è esauriti i ricordi? Uccidi il maiale o rallenta a causa della mancanza di memoria per la cache del disco.
psusi,

2
@TomWijsman, Disk IO è molto più lento di molti ordini di grandezza rispetto all'IO di memoria, quindi l'utilizzo di disk swap ha sempre significato un enorme rallentamento. A volte (specialmente ai vecchi tempi in cui il montone era costoso e quindi la maggior parte delle persone non ne aveva molto) è preferibile non poter fare quello che stavi provando. In questi giorni il disco è SO molto più lento di ram, e la RAM è abbastanza a buon mercato che la maggior parte delle persone hanno un sacco, così nelle rare occasioni in cui accidentalmente eseguire qualcosa che utilizza più ram di quello che hanno, spesso è meglio rinunciare che prendere 1000 tempi lunghi per farlo.
psusi

Risposte:


36

Ho anche lottato con questo problema. Voglio solo che il mio sistema rimanga reattivo, qualunque cosa accada, e preferisco perdere i processi ad aspettare qualche minuto. Sembra che non ci sia modo di ottenere questo risultato usando il kernel oom killer.

Tuttavia, nello spazio utente, possiamo fare quello che vogliamo. Quindi ho scritto Early OOM Daemon ( https://github.com/rfjakob/earlyoom ) che ucciderà il processo più grande (tramite RSS) una volta che la RAM disponibile sarà inferiore al 10%.

Senza earlyoom, è stato facile bloccare la mia macchina (8 GB di RAM) avviando alcune volte http://www.unrealengine.com/html5/ . Ora, le schede del browser colpevoli vengono uccise prima che le cose sfuggano di mano.


3
Grazie per aver graffiato questo prurito! Finora amorevole fino ad ora.
Thomas Ferris Nicolaisen,

1
Ho appena capito che Android fa lo stesso da molto tempo. Non sono sicuro se stia usando un codice personalizzato come il tuo per questo.
dronus,

1
Sto testando earlyoomora, funziona bene in un primo test trigger. Mi chiedo solo perché questo non può essere implementato dalla configurazione del kernel o dagli strumenti di sistema.
dronus,

12

La politica di default del kernel è di consentire alle applicazioni di continuare ad allocare memoria virtuale fintanto che c'è memoria fisica libera. La memoria fisica non viene effettivamente utilizzata fino a quando le applicazioni non toccano la memoria virtuale che hanno allocato, quindi un'applicazione può allocare molta più memoria di quella del sistema, quindi iniziare a toccarla in seguito, causando l'esaurimento della memoria del kernel e l'attivazione del killer della memoria (OOM). Tuttavia, prima che il processo di hogging venga interrotto, la cache del disco è stata svuotata, il che rende il sistema lento a rispondere per un po 'fino a quando la cache non si riempie.

È possibile modificare il criterio predefinito per impedire il sovraccarico della memoria scrivendo un valore di 2 in /proc/sys/vm/overcommit_memory. Il valore predefinito /proc/sys/vm/overcommit_ratioè 50, quindi il kernel non consentirà alle applicazioni di allocare più del 50% di ram + swap. Se non hai swap, il kernel non consentirà alle applicazioni di allocare più del 50% del tuo ram, lasciando l'altro 50% libero per la cache. Potrebbe essere un po 'eccessivo, quindi potresti voler aumentare questo valore per dire, circa l'85%, quindi le applicazioni possono allocare fino all'85% del tuo ram, lasciando il 15% per la cache.


1
La modifica di questi valori da lì predefiniti senza background teorico non raggiungerà un sistema più affidabile, è possibile giustificare tale modifica solo con statistiche adeguate. Solo perché puoi cambiarlo non significa che dovresti. Se sei costantemente in condizioni di memoria insufficiente, ciò significa che stai utilizzando più memoria di quella che hai e dovresti acquistare più memoria, ciò non significa che dovresti giocherellare con le tue impostazioni e uccidere applicazioni casuali. Interrompere il lavoro quotidiano o introdurre la corruzione non è davvero la strada da percorrere ...
Tamara Wijsman,

3
@TomWijsman, la domanda chiarisce che non è costantemente in condizioni di memoria insufficiente; a volte esegue un comando che richiede inaspettatamente una grande quantità di memoria. L'acquisto di più memoria non è l'unica soluzione quando si esaurisce. Altre potenziali soluzioni includono la ricerca di modi migliori per utilizzare la memoria che hai o semplicemente non fare tutto ciò che ha bisogno di tanta memoria. La domanda chiarisce che quest'ultimo è più accettabile che uscire e comprare più ram.
psusi

Quale riga nella domanda lo chiarisce? Vedo il contrario I disabled swap, because for GUI usage it mostly renders the machine unresponsive in such a way not useable anymore.. Ha menzionato la GUI, mentre si presume che esegua un comando. L'acquisto di più memoria è la prima soluzione, l'utilizzo di meno memoria è la seconda soluzione, rendendo instabile il tuo sistema manipolando i valori predefiniti stabili è l'ultima soluzione. Non è necessario rispondere alla domanda alla lettera, quindi non vedo quale sia il tuo problema che devi disturbare entrambi nei commenti. Rant non aiuta ...
Tamara Wijsman,

4
Ehi, questa risposta sembrava abbastanza interessante. Sfortunatamente, il "commit" si riferisce alla domanda di memoria virtuale che sembra, il che è abbastanza male stimato dai programmatori di applicazioni. Ad esempio con il mio desktop (no swap) in esecuzione, ci sono circa 400 di 2000 MB di memoria fisica utilizzata, ma 1600 mb /proc/meminfosono Committed_ASstati commessi come stati. Con alcune applicazioni in esecuzione, questo valore supera facilmente la memoria fisica, quindi è difficile impostare un limite realizzabile da questo.
dronus,

3
Salva il tuo lavoro prima di provare questo! : PI ha avuto fallimenti immediati da tutto (bash, window manager ecc.).
jozxyqk,

8

Per me l'impostazione di vm.admin_reserve_kbytes = 262144 fa esattamente questa cosa. Gli assassini di OOM intervengono prima che il sistema non risponda completamente.


1
Mi piace l'idea, ma significa che non hai mai usato 256 MiB di memoria fisica?
Jérôme Pouiller,

1
256 MB verranno utilizzati per le cache. Le cache sono davvero importanti, non si tratta solo di correre più velocemente, il sistema non funzionerebbe affatto se non ci fosse abbastanza memoria per le cache. Il codice di ogni programma in esecuzione può essere scaricato dalla memoria perché è mmaped e può essere riletto dal disco. Senza cache ogni switch di attività richiederà la lettura del disco e il sistema non risponderà completamente.
Michael Vigovsky,

4

Le altre risposte hanno buone soluzioni automatiche, ma trovo che possa essere utile abilitare anche la SysRqchiave per quando le cose sfuggono di mano. Con la SysRqchiave, invieresti manualmente il messaggio al kernel e potrai fare cose come un riavvio sicuro (con SysRQ + REISUB) anche se userspace è completamente bloccato.

Per consentire al kernel di ascoltare le richieste, impostare kernel.sysrq = 1o abilitare solo le funzioni che è probabile che si usi con una maschera di bit (documentata qui ). Ad esempio kernel.sysrq = 244abiliterà tutte le combo necessarie per il riavvio sicuro sopra e l'invocazione manuale del killer OOM con SysRq + F.


-2

L'affidabilità non è raggiunta da condizioni di memoria insufficiente e da un killer OOM.

È sbagliato organizzare una festa in un armadio e posizionare "ripulendo il mio armadio" nella tua piccola playlist.

È possibile far intervenire l'assassino OOM prima?

In questo modo si otterranno risultati collaterali indesiderati, poiché non si ha il controllo su ciò che viene ucciso.

Cerco di ottimizzare il mio sistema di sviluppo per la massima affidabilità.

La massima affidabilità implica il test del sistema e il miglioramento del sistema in base a questi test.

Basta modificare le cose casuali non ti porterà da nessuna parte ...

Ho disabilitato lo scambio, perché per l'utilizzo della GUI la macchina non risponde in gran parte in modo tale da non essere più utilizzabile. Ciononostante, se le appicciche aggressioni divorano la memoria, alcuni meccanismi sembrano dare il via a quello sfruttando al massimo il costo della velocità.

A causa delle condizioni di memoria insufficiente, disabilitare lo scambio non migliorerà il comportamento , ma farà il contrario .

Per aumentare l'affidabilità in questa situazione, aggiungi più memoria in modo che il tuo sistema sia più reattivo e non ci siano processi casuali che vengono uccisi senza l'intenzione dell'utente. Non dovresti ricorrere a condizioni di memoria insufficiente e un meccanismo come questo, soprattutto non in un ambiente di sviluppo ...

Non vi è alcuna operazione di sostituzione del disco rigido, ma anche il sistema non risponde.

Le condizioni di memoria insufficiente si traducono effettivamente in non risposta, sia che si abbia uno scambio o meno.

Quindi voglio lasciare che il killer OOM entri in azione prima che il sistema faccia uno sforzo speciale per guadagnare memoria.

Sforzi speciali che faranno più male che bene, come ho spiegato sopra. Invece, potresti uccidere i processi che non ti servono, ma immagino che non puoi farlo, quindi OOM ucciderà i processi di cui hai bisogno.

È possibile configurare il killer OOM affinché agisca se, ad esempio, c'è meno di 100 MB di memoria fisica libera?

Potrebbe essere, ma otterrai un ritorno sull'investimento più elevato se acquisti solo un po 'di memoria extra che in questi giorni non costa molto. Considera che ti colpirai a lungo nel piede se continui a lavorare con condizioni di memoria insufficiente. OOM è come un ufficiale giudiziario, non ti aiuta, assiste il sistema operativo ...


7
Ovviamente la disabilitazione dello swap migliora il comportamento perché invece di schiacciare il disco, l'OOM entra e uccide il porco di memoria. A corto di ram non è il problema (e l'aggiunta di più significa solo che devi impegnarti di più per esaurire). Il problema è cosa fare quando finisci. Vuoi che OOM uccida il porco e quindi allevi la condizione di memoria insufficiente.
psusi,

7
Perché uccidere un'applicazione che sta cercando di utilizzare più memoria di quella che hai è preferibile per mettere in ginocchio l'intero sistema. In un mondo perfetto avresti memoria illimitata e non finiresti mai, ma in realtà, a volte finisci per caso e preferiresti sentirti dire "memoria insufficiente" piuttosto che fermare il sistema.
psusi

5
L'acquisto di memoria aggiuntiva potrebbe risolvere alcuni problemi, a seconda della quantità acquistata. Ma non cambia il fatto che potrebbero esserci usi imprevisti per ordini di grandezza. Quindi voglio che l'applicazione fallisca, ma NON il sistema in quelle condizioni. Alcuni esempi: elaborare una cartella piena di immagini compresse, la maggior parte delle quali di dimensioni "normali", ma alcune di esse molto grandi. Un piccolo errore potrebbe causare un dead loop con una fuga di memoria che consuma 1 GB / s. Apri accidentalmente un file video in un editor di testo. Di solito questo termina con sintomi come un topo a scatti e
un'interfaccia

6
@TomWijsman ci sono anche loop quasi morti in quanto esistono algoritmi che si comportano in modo lineare nel caso medio ma esponenziali nel caso peggiore, a seconda dei dati di input. E non posso inviare un segnale di arresto se il mouse è a scatti e i clic e l'input da tastiera mostrano una latenza di un minuto. Di solito passo a un terminale in modalità testo e aspetto minuti per il login di procedere solo per emettere un killcieco.
dronus,

7
Non ho problemi con l'uccisione di applicazioni che sarebbero morte. Prendi in considerazione un sistema con scambio fisico da 2 GB + 2 GB. Un'applicazione che esaurisce rapidamente la memoria fisica può facilmente consumare anche lo scambio. Sarebbe morto dopo, dopo aver reso il sistema non rispondente per minuti o ore. Quindi perché non ucciderlo rapidamente prima che l'operazione della GUI diventi instabile? Molti processi svolgono tutto il loro lavoro con 10 MB, alcuni richiedono 1 GB e alcuni rari richiedono 10 GB, questa è la vita.
dronus,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.