O Kernel 3.15 adiciona mais controle ao cache da página. Muitos servidores de aplicativos não requerem o disco pesado io. Se for esse o caso, basta adicionar um cron job:
echo 1 > /proc/sys/vm/drop_caches
Eu tenho um serviço web baseado no PostgreSQL em dois servidores Debian, um um vhost rodando Linux kernel 3.2.0-2 com 2GB de RAM e o outro um servidor dedicado rodando o kernel Linux 2.6.26-1 com 6 GB de RAM. Embora o aplicativo tenha um espaço de memória muito pequeno, com o tempo o cache preenche uma certa quantidade na qual os processos são trocados aumentando a carga do sistema, finalmente ficam sem memória e, eventualmente, travam o kernel (mesmo comportamento em ambos os sistemas, somente diferentes períodos de tempo). Antes das falhas, free -m informa algo semelhante a:
$ free -m
total used free shared buffers cached
Mem: 1978 1583 394 0 147 1208
-/+ buffers/cache: 227 1751
Se eu reinicializar o sistema, ele funcionará sem problemas por algum tempo (geralmente semanas ou meses, mas às vezes apenas dias) até que o cache seja preenchido novamente. Após a reinicialização, free -m relatórios:
$ free -m
total used free shared buffers cached
Mem: 1978 452 1526 0 6 302
-/+ buffers/cache: 143 1835
Seria aceitável para mim se o servidor diminuísse um pouco devido à E / S do disco se houvesse picos devido ao uso excessivo, mas não é aceitável que o sistema trave então e quando a memória cache de disco não é recuperada para processos se precisarem temporariamente de mais memória.
Portanto, em um servidor eu desabilitei a troca (já que com a troca a carga sobe para 300 - 400 (em uma espécie de reação em cadeia se processos estão sendo mortos) tornando o sistema inutilizável mesmo para um login remoto para iniciar uma reinicialização Além disso, eu defini o parâmetro de ajuste do kernel vm.swappiness=0 e vm.overcommit_memory=2 como recomendado no guia de Ajuste de Alto Desempenho do PostgreSQL para forçar o kernel a recuperar memória do cache e evitar over-committing.
Mas isso parece não ter o efeito desejado - a saída acima de free não mostrou um cache decrescente enquanto os programas novamente começaram a travar com no memory available mensagens de erro (a saída acima de free foi produzida apenas alguns segundos depois que as primeiras mensagens no memory available apareceram no syslog após cerca de dois meses de operação suave).
Existe alguma chance de evitar esse cache excessivo para poder usar a memória para os aplicativos, em vez de usar a E / S de disco?
Aumentar a memória física não ajudou, pois no sistema equipado com 6GB obtive os mesmos resultados mais cedo ou mais tarde quando mais clientes se conectaram ao serviço (é um servidor de autenticação hotspot para uso público gratuito com um número desconhecido de usuários e eu precisa ficar com os dois servidores por algum tempo por causa de várias razões). No vhost, usei pela primeira vez 1 GB, agora 2 GB - sendo o limite para o meu vhost - e tudo o que consegui até agora foi um aumento no armazenamento em cache, mas não na memória dos processos. É assim que deveria funcionar no Linux? Apenas 12% de memória para processos? Ou as sugestões acima do livro HPT estão incorretas?
Agradecemos antecipadamente por qualquer dica!
Olá Michael, sim, parece que sim. Eu também pensei que a memória cache do kernel deveria ser liberada se os aplicativos de usuário precisassem de mais memória. Mas olhe para essa saída de free(1) que ocasionalmente observei quando o sistema deixou de responder novamente, o que é um sinal de que a situação leva o assassino de OOM a ser expulso mais cedo ou mais tarde:
total used free shared buffers cached
Mem: 1978 981 997 0 142 638
-/+ buffers/cache: 200 1777
Swap: 0 0 0
Eu posso ver o free Mem descendo para zero, enquanto o -/+ buffers/cache ainda mostra algum valor alto antes que o sistema eventualmente falhe. Eu imediatamente limpei o cache em sync ing e gravei 3 em /proc/sys/vm/drop_caches resultando na liberação da memória do kernel:
total used free shared buffers cached
Mem: 1978 481 1496 0 1 283
-/+ buffers/cache: 196 1782
Swap: 0 0 0
Então, como uma solução alternativa, estou limpando o cache manualmente de tempos em tempos. Infelizmente não posso apenas atualizar o sistema operacional no sistema de produção, mas tenho que alterar os sistemas antes das atualizações para garantir 99% de disponibilidade. O teste de kernels em nosso sistema de teste é possível, mas inútil, já que a situação descrita só aparecerá depois de um certo tempo em nosso sistema de produção, atendendo a dezenas de milhares de solicitações de login por dia.
BTW, esta é a saída de free -m para hoje:
total used free shared buffers cached
Mem: 1978 1107 871 0 146 753
-/+ buffers/cache: 207 1771
Swap: 0 0 0
Se eu entendi corretamente, os aplicativos e o kernel usam cerca de 190 a 227 MB, enquanto os buffers e o cache consomem o restante da memória. Tenho certeza de que o problema não está relacionado a algum aplicativo, já que nada muda se eu reiniciar os aplicativos, mas isso ajuda a limpar o cache manualmente.
O Kernel 3.15 adiciona mais controle ao cache da página. Muitos servidores de aplicativos não requerem o disco pesado io. Se for esse o caso, basta adicionar um cron job:
echo 1 > /proc/sys/vm/drop_caches
Tags performance cache memory linux