Puoi impostare una dimensione minima del buffer del disco linux?

Ho una macchina Linux piuttosto vecchia con 2 GB di RAM, senza scambio, e funziona molto bene, con il sistema che utilizza ogni pezzo di memoria inutilizzato per la memorizzazione nella cache con grande effetto.

Tuttavia, quando sono vicino a stressare la memoria (ad es.> 1950MB allocati), rallenta a gattonare; Sospetto perché non siano rimasti buffer del disco. So che il killer OOM entrerebbe presto in vigore, ma di solito non ci arriva - sta diventando così lento che carica gli scatti a 30-40, nessun processo fa alcun progresso (quindi non alloca più memoria) e Devo riavviarlo.

Quando provo a interrompere un solo processo per ottenere la risposta della macchina, ad esempio andando alla console (tramite Alt-F1, eseguendo l'accesso e facendo semplicemente un "processo killall"), di solito funziona, tranne che devo aspettare ~ 10 minuti tra utente / password e ricezione di un prompt, il tutto durante l'attività del disco.

Ancora una volta, non c'è scambio, quindi non si scambia - si sta solo schiantando perché non ha buffer.

Avrei molto dedicato circa 100 MB esclusivamente ai buffer del disco, il che avrebbe innescato il killer OOM in precedenza (meno memoria per i programmi, dopotutto) ma d'altra parte avrebbe lasciato la macchina reattiva in ogni momento.

C'è un modo per farlo? Non sono stato in grado di trovare una voce / proc / kernel o / sys / vm che faccia questo tipo di cose.

linux cache

— HopelessN00b
fonte

Ho anche lo stesso problema, e purtroppo nessuna delle risposte a questa data è di aiuto in questa materia.

— Krišjānis Nesenbergs,

Risposte:

Dai un'occhiata a / proc / sys / vm / min_free_kbytes . È il limite di kbyte liberi che innesca il killer di Oom. Inoltre sarebbe bene controllare nei registri la parola chiave oom-killer per sapere cosa viene ucciso {probabilmente non vuoi uccidere ssh , è meglio rinominarlo }

— Nikolaidis Fotis
fonte

Grazie. L'ho ingrandito, ma questo non sembra risolvere il problema: una volta che la memoria fisica è stata quasi esaurita, non è rimasta memoria buffer e la macchina ha rallentato a passo d'uomo.

Nessun aiuto neanche qui, il sistema continua a non rispondere.

— Tronic,

Questo in realtà mi ha aiutato, ho anche 2 GB di RAM e ho impostato questo su quasi 500 MB - per ora nessun rallentamento / blocco

— Krišjānis Nesenbergs

Attualmente sto testando questa impostazione sulla mia workstation. Ho 8 GB di RAM e la maggior parte delle volte non ne uso più di 5 ... tranne quando per qualche motivo devo avviare una VM Windows che richiede circa 4 GB di RAM. Ho ZRAM impostato sul mio SO host perché il mio disco rigido è meccanico, ma diventa ancora piuttosto lento con la RAM quasi piena a causa proprio dello spazio RAM ridotto per i buffer e le cache del filesystem. Ho appena usato vm.min_free_kbytes per assicurarmi di avere sempre almeno 2 GB liberi e di avere il resto impaginato sulla RAM zippata (che è molto più veloce del normale spazio di scambio). Pubblicheremo più tardi con i risultati.

— RAKK,

Aspettare che il killer di Oom liberi la memoria è un po 'come aspettare che il motore si fermi sulla tua auto per dirti quando è il momento di riempire il serbatoio del gas. Oom-Killer è uno strumento pesante di ultima istanza e disperazione per una macchina affamata di risorse. Uccide il prossimo programma che tocca senza considerare come ciò influenzerà l'applicazione, la raggiungibilità, l'affidabilità e così via. Quando viene invocato l'omicida, il tuo server ansima per il respiro e in condizioni critiche.

Invece, è molto meglio adottare un approccio attivo nella gestione dell'utilizzo della memoria all'interno dell'ambiente applicativo. È possibile monitorare / proc / meminfo per individuare eventuali problemi e intraprendere le azioni appropriate e ridurre il carico di lavoro prima che una situazione grave diventi brutta.

— tylerl
fonte

La situazione che ho scoperto è esattamente il momento in cui il mio server è senza fiato e in condizioni critiche. Sono necessari meno di 20 secondi da una macchina completamente reattiva a 1 minuto per rispondere a Ctrl-Alt-F1 (passare da X a console). E l'accesso è impossibile perché scade dopo 1 minuto senza nemmeno chiedere una password. Questa è una macchina che ha molti processi in esecuzione; ognuno NON è indipendentemente il problema. Inoltre, questo è strettamente un problema di memoria: la CPU va bene e il disco va bene fino a quando rimangono circa 50 MB di buffer del disco.

cosa succede se si utilizza ulimit e se un'applicazione utilizza oltre una soglia per eseguire un'azione?

— Nikolaidis Fotis,

Il problema è la somma di tutte le applicazioni; Circa 20 sono in esecuzione, ciascuno con 20-100 MB assegnati. Funziona bene per settimane, anche mesi, ma quando tutti vogliono avere ~ 100 MB allocati allo stesso tempo, tutto si blocca e brucia; Preferirei che oom_killer uccidesse uno di loro piuttosto che dover riavviare la macchina. Ad ogni modo, per ora ho attivato lo scambio: la maggior parte delle app non usa sempre tutta la memoria, quindi la macchina rimane stabile anche quando è stressata fino alla fine della memoria fisica; tuttavia, preferirei non avere alcun cambio per questa macchina, se posso.

Non risolve il problema reale che è una combinazione di non essere quello di impostare limiti di utilizzo della memoria adeguati (gli ulimit non sono molto utili), le applicazioni vanno facilmente in rovina con allocazioni di memoria, il killer OOM non riesce a sparare abbastanza presto e l'enorme distruzione del disco e la mancanza di risposta causato da tutto ciò. Ho appena perso 30 minuti di tempo del mio datore di lavoro perché la macchina di sviluppo ha eliminato il disco per mezz'ora durante la compilazione del mio codice, invece di semplicemente uccidere i processi di Chromium necessari per uccidere (o la compilazione stessa) in meno di un secondo e poi essere fatto con esso.

— Tronic,

Se impostato oom_adjcorrettamente, puoi far funzionare il tuo sistema desktop un po 'come Android, dove il sistema è praticamente sempre in esecuzione contro Killer OOM (tecnicamente c'è un "killer a bassa memoria" ed è sintonizzato tramite /sys/module/lowmemorykiller). La logica è di contrassegnare continuamente i processi di base non critici come potenziali vittime del killer OOM e cercare processi uccisi e riavviare lentamente i programmi uccisi richiesti per evitare di sovraccaricare il sistema. Assicurati solo che il processo che continua a riavviare altri processi sia contrassegnato dai limiti per OOM Killer.

— Mikko Rantalainen,