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

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

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.

Aparentemente, o postgres ' shared_bufferspode aparecer cached, apesar de não ser facilmente descartável ... Consulte OOM, apesar da memória disponível (cache)