Execução do Ubuntu em um kernel 2.6.31-302 x86-64. O problema geral é que eu tenho memória na categoria 'em cache' que continua subindo e não será liberada ou usada mesmo quando o aplicativo precisar dela.
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. O "cache" 1,4 GB aqui parece ser reservado e inutilizável.
Meu conhecimento do Linux me diz que 3 GB é "grátis"; mas o comportamento do sistema diz o contrário. Quando o 1,6 GB de memória livre real é usado durante o uso de pico, assim que mais memória é exigida (e o 'livre' na primeira coluna se aproxima de 0) o killer da OOM é invocado, processos são eliminados e problemas começam a surgir mesmo que o 'livre' na linha - / + buffers / cache ainda tenha aproximadamente 1.4 GB 'livre'.
Eu ajustei os valores oom_adj nos principais processos para que ele não ponha o sistema de joelhos, mas mesmo assim processos importantes serão eliminados, e nunca queremos chegar a esse ponto. Especialmente quando, teoricamente, 1,4GB ainda está "livre" se apenas for liberado o cache de disco.
Alguém tem alguma ideia do que está acontecendo aqui? A internet é inundada com as perguntas idiotas sobre o comando 'livre' 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 aparece na minha cabeça é que a troca está desativada. Nós temos um administrador de sistema que é inflexível sobre isso; Eu estou aberto a explicações se elas estiverem armazenadas em backup. Isso poderia causar problemas?
Aqui está livre depois de executar 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 é liberada, mas cerca de 1,4 GB parece estar "preso". O outro problema é que esse valor parece aumentar com o tempo. Em outro servidor, 2,0 GB está preso.
Eu realmente gostaria de ter essa lembrança de volta ... qualquer ajuda seria muito apreciada.
Aqui está cat /proc/meminfo se vale a pena:
# 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
Eu descobri a resposta para minha própria pergunta - graças à ajuda do womble (envie uma resposta se você quiser).
lsof -s mostra as alças de arquivos em uso e, no final, havia vários gigabytes de arquivos de log mmap'd ocupando o cache.
A implementação de um logrotate deve resolver o problema completamente e permitir que eu aproveite mais memória.
Eu também reativei o swap, assim não teremos problemas com o killer da OOM no futuro. Obrigado.
Aparentemente, o postgres ' shared_buffers pode aparecer em cached , embora não seja facilmente descartável ... Consulte OOM apesar da memória disponível (cache)