Linux não liberando cache de disco grande quando a demanda de memória aumenta

24

Executando o Ubuntu em um kernel 2.6.31-302 x86-64. O problema geral é que tenho memória na categoria 'em cache' que continua subindo e não será liberada ou usada mesmo quando nosso aplicativo precisar.

Então aqui está o que eu recebo do comando 'free'. Nada disso parece fora do comum à primeira vista.

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

A primeira coisa que alguém vai dizer é "Não se preocupe, o Linux gerencia essa memória automaticamente". Sim, eu sei como o gerenciador de memória deve funcionar; o problema é que não está fazendo a coisa certa. Os 1,4 GB "em cache" aqui parecem reservados e inutilizáveis.

Meu conhecimento do Linux me diz que 3 GB são "gratuitos"; mas o comportamento do sistema diz o contrário. Quando os 1,6 GB de memória livre real são usados ​​durante o uso de pico, assim que mais memória é exigida (e o 'livre' na primeira coluna se aproxima de 0), o killer do OOM é invocado, os processos são eliminados e os problemas começam a surgir mesmo que o 'free' na linha - / + buffers / cache ainda tenha cerca de 1,4 GB 'free'.

Ajustei os valores oom_adj nos principais processos para que não deixasse o sistema de joelhos, mas mesmo assim processos importantes serão eliminados e nunca queremos chegar a esse ponto. Especialmente quando, teoricamente, 1,4 GB ainda está "livre" se apenas expulsar o cache do disco.

Alguém tem alguma idéia do que está acontecendo aqui? A Internet está cheia de perguntas idiotas sobre o comando 'free' do Linux e "por que não tenho memória livre" e não consigo encontrar nada sobre esse problema por causa disso.

A primeira coisa que me vem à cabeça é que a troca está desativada. Temos um administrador de sistema que é inflexível sobre isso; Estou aberto a explicações se eles tiverem backup. Isso poderia causar problemas?

Aqui está livre após a execução 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

Como você pode ver, uma quantidade minúscula de cache é realmente liberada, mas cerca de 1,4 GB parece estar "travado". O outro problema é que esse valor parece aumentar ao longo do tempo. Em outro servidor, 2,0 GB estão presos.

Eu realmente gostaria dessa memória ... qualquer ajuda seria muito apreciada.

Aqui está cat /proc/meminfose vale alguma coisa:

# 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
linux memory memory-usage disk-cache trisweb
fonte
3
Eu não tenho nenhuma explicação para o seu cache (embora eu suspeite que os arquivos mmap'd provavelmente entrem nele), mas para o bem da humanidade, pegue uma pá e um pouco de calda e se livre do "você não precisa trocar" se você tem muita memória RAM! " reforço. Eles são imunes à discussão racional e estão perigosamente errados. O fato de o assassino da OOM estar perseguindo você é apenas um sintoma disso.
Womble
Meus pensamentos exatamente. Obrigado pelo conselho. Você conhece outros bons artigos ou argumentos sobre por que a troca é necessária?
trisweb
6
Porque se você não tem troca, coisas assim acontecem. Mas não se preocupe em tentar discutir com o seu negador da troca; quer quebrar o cal ou dizer "se você não quiser trocar aqui, você consertar essa bagunça que você insistiu em criar". Eventualmente, eles mesmos mudarão de idéia ou morrerão tentando. Problema resolvido de qualquer maneira.
womble
Excelente, obrigado pelas dicas. A propósito, você estava certo sobre os arquivos mmap'd - um rápido lsof mostrava shows de arquivos de log ocupando a memória. Eliminá-los resolveu o problema.
trisweb
O problema é que, sem troca, a confirmação excessiva resulta na execução do OOM killer e a não confirmação excessiva resulta em um sistema que não pode iniciar processos. Você precisa trocar para fazer uso efetivo da RAM.
David Schwartz

Respostas:

8

Descobri a resposta para minha própria pergunta - graças à ajuda do womble (envie uma resposta, se quiser).

lsof -s mostra identificadores de arquivo em uso e verifica-se que havia vários gigabytes de arquivos de log mmap'd ocupando o cache.

A implementação de uma rotação de log deve resolver o problema completamente e permitir que eu aproveite mais memória.

Também reativarei a troca, para que não tenhamos problemas com o OOM killer no futuro. Obrigado.

trisweb
fonte
2
As páginas mmap são descartáveis, de modo que não devem ser fixados no cache. Você está usando um ramfs?
Psusi 12/07/11
Olá, desculpe desenterrar um tópico antigo, mas estou enfrentando o mesmo problema no momento e lsof -snão mostra nenhum uso incomum. No entanto, estou usando um ramfs como você disse [e o kernel 2.6.10, que não possui o recurso drop_caches]. O que você acha que é o provável suspeito?
Ram #
1
Obrigado pela dica! Estou adicionando lsof -s | sort -rnk 7 | lessà minha caixa de ferramentas agora. Uma observação para outros leitores: isso pode significar grandes entradas /proc/net/rpc/nfs4.nametoid/channel, mas elas não se mostraram as culpadas no meu caso.
Nickolay
verifique se seus arquivos ou programas grandes não estão usando o mlock. em /proc/meminfopáginas "inevitáveis".
Michael Martinez