Linux non libera la cache del disco di grandi dimensioni quando aumenta la richiesta di memoria


24

Esecuzione di Ubuntu su un kernel 2.6.31-302 x86-64. Il problema generale è che ho memoria nella categoria 'cache' che continua a salire e non verrà liberata o utilizzata anche quando la nostra applicazione ne ha bisogno.

Quindi, ecco cosa ottengo dal comando 'free'. Niente di tutto ciò sembra fuori dal comune a prima vista.

# free
             total       used       free     shared    buffers     cached
Mem:       7358492    5750320    1608172          0       7848    1443820
-/+ buffers/cache:    4298652    3059840
Swap:            0          0          0

La prima cosa che qualcuno dirà è "Non preoccuparti, Linux gestisce automaticamente quella memoria". Sì, so come dovrebbe funzionare il gestore della memoria; il problema è che non sta facendo la cosa giusta. I 1,4 GB "memorizzati nella cache" qui sembrano essere riservati e inutilizzabili.

La mia conoscenza di Linux mi dice che 3 GB sono "gratuiti"; ma il comportamento del sistema dice il contrario. Quando 1,6 GB di memoria libera reale vengono esauriti durante l'utilizzo di picco, non appena viene richiesta più memoria (e il "libero" nella prima colonna si avvicina a 0) viene invocato il killer OOM, i processi vengono uccisi e iniziano a sorgere problemi anche se il "libero" nella riga - / + buffer / cache ha ancora circa 1,4 GB "libero".

Ho messo a punto i valori di oom_adj sui processi chiave in modo che non metta in ginocchio il sistema, ma anche in questo caso i processi importanti verranno eliminati e non vogliamo mai raggiungere quel punto. Soprattutto quando, in teoria, 1,4 GB è ancora "libero" se sfrattasse solo la cache del disco.

Qualcuno ha idea di cosa sta succedendo qui? Internet è inondato dalle domande stupide sul comando "gratuito" di Linux e "perché non ho memoria libera" e non riesco a trovare nulla su questo problema a causa di ciò.

La prima cosa che mi viene in mente è che lo swap è disattivato. Abbiamo un amministratore di sistema che è irremovibile al riguardo; Sono aperto alle spiegazioni se sono state salvate. Questo potrebbe causare problemi?

Ecco gratis dopo l'esecuzione echo 3 > /proc/sys/vm/drop_caches:

# free
             total       used       free     shared    buffers     cached
Mem:       7358492    5731688    1626804          0        524    1406000
-/+ buffers/cache:    4325164    3033328
Swap:            0          0          0

Come puoi vedere, una piccola quantità di cache viene effettivamente liberata, ma circa 1,4 GB sembra essere "bloccato". L'altro problema è che questo valore sembra aumentare nel tempo. Su un altro server 2,0 GB è bloccato.

Mi piacerebbe davvero questo ricordo ... qualsiasi aiuto sarebbe molto apprezzato.

Ecco cat /proc/meminfose vale qualcosa:

# cat /proc/meminfo 
MemTotal:        7358492 kB
MemFree:         1472180 kB
Buffers:            5328 kB
Cached:          1435456 kB
SwapCached:            0 kB
Active:          5524644 kB
Inactive:          41380 kB
Active(anon):    5492108 kB
Inactive(anon):        0 kB
Active(file):      32536 kB
Inactive(file):    41380 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:               320 kB
Writeback:             0 kB
AnonPages:       4125252 kB
Mapped:            42536 kB
Slab:              29432 kB
SReclaimable:      13872 kB
SUnreclaim:        15560 kB
PageTables:            0 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     3679244 kB
Committed_AS:    7223012 kB
VmallocTotal:   34359738367 kB
VmallocUsed:        7696 kB
VmallocChunk:   34359729675 kB
DirectMap4k:     7340032 kB
DirectMap2M:           0 kB

3
Non ho alcuna spiegazione per la tua cache (anche se sospetto che i file mmap'd probabilmente entrino in essa), ma per il bene dell'umanità, prendi una pala e un po 'di calce viva e sbarazzati del "non hai bisogno di scambiare se hai molta RAM! " booster. Sono immuni alla discussione razionale e sono pericolosamente sbagliati. Il fatto che il killer OOM ti stia perseguitando è solo un sintomo di questo.
Womble

I miei pensieri esattamente. Grazie per il consiglio. Conosci altri buoni articoli o argomenti sul perché è necessario lo scambio?
trisweb,

6
Perché se non hai uno scambio, succedono cose del genere. Ma non preoccuparti di provare a litigare con il tuo negatore swap; o rompere la calce viva o dire "se non si vuole swap qui, si risolvere questo casino che hai insistito sulla creazione di". O alla fine cambieranno idea da soli o moriranno provandoci. Problema risolto in entrambi i modi.
womble

Eccellente, grazie per i suggerimenti. A proposito, avevi ragione sui file mmap'd: una rapida lsof mostrava concerti di file di log che occupavano memoria. Eliminandoli è stato risolto il problema.
trisweb,

Il problema è che senza swap, il commit eccessivo provoca l'esecuzione del killer OOM e non il commit eccessivo dei risultati in un sistema che non può avviare i processi. È necessario lo scambio per utilizzare in modo efficace la RAM.
David Schwartz,

Risposte:


8

Ho scoperto la risposta alla mia domanda, grazie all'aiuto di Womble (invia una risposta se vuoi).

lsof -s mostra gli handle di file in uso e risulta che c'erano diversi gigabyte di file di registro mmap che occupavano la cache.

L'implementazione di un logrotate dovrebbe risolvere completamente il problema e permettermi di sfruttare più memoria.

Riattiverò anche lo swap in modo da non avere problemi con il killer OOM in futuro. Grazie.


2
Le pagine mmap'd sono scartabili, quindi ciò non dovrebbe causare il blocco della cache. Stai usando un ramfs?
psusi,

Ciao, mi dispiace scavare un vecchio thread, ma sto affrontando lo stesso problema attualmente e lsof -snon mostra alcun uso insolito. Comunque, sto usando un ramfs come hai detto [e il kernel 2.6.10, che non ha la funzione drop_caches]. Quale pensi sia il probabile sospettato?
Ram

1
Grazie per il consiglio! Sto aggiungendo lsof -s | sort -rnk 7 | lessalla mia cassetta degli attrezzi ora. Una nota per gli altri lettori: questo potrebbe includere voci di grandi dimensioni /proc/net/rpc/nfs4.nametoid/channel, ma non si sono rivelate colpevoli nel mio caso.
Nickolay,

assicurati che i tuoi file o programmi di grandi dimensioni non utilizzino mlock. nelle /proc/meminfopagine "Inevitabili".
Michael Martinez,

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.