O cache de páginas do Linux retarda o IO no servidor de CPU dupla com 64 GB de RAM

Question

Eu tenho um grande problema com o cache da página do Linux, que retarda o IO. Por exemplo, se eu copiar uma partição lvm com dd, o Linux armazena em cache os dados nos buffers ou caches (free –m). Esse não é o problema, mas depois que o buffer atinge um valor especial, o processo de cópia para e fica lento para alguns mbs ou até kbs. Eu fiz muitos testes com gravação em disco ou/dev/null, o problema não tem nada a ver com a unidade de origem ou destino.

Em detalhe:

• Existem dois servidores quase idênticos. Ambos rodando CentOS 6.5 com o mesmo kernel. Eles têm os mesmos discos, a mesma configuração, o mesmo hardware, iguais em todos os aspectos. A única diferença é que um servidor possui 2 CPUs e 64 GB de RAM e o outro 1 CPU e 32 GB de RAM.
• Aqui também está uma imagem do seguinte processo de cópia:https://i.stack.imgur.com/tYlym.jpg
• Aqui está uma nova versão também com meminfo. O meminfo é de uma execução diferente, portanto os valores não são idênticos, mas é o mesmo comportamento:https://i.stack.imgur.com/4SIJG.jpg
• Inicie a cópia com dd ou outro programa de cópia do sistema de arquivos.
• O buffer ou cache começa a encher. Está tudo bem.
• O buffer ou cache atinge um número máximo (em um servidor de 64 GB de RAM, um valor como 32 GB ou 17 GB; em um servidor de 32 GB de RAM, toda a memória livre)
• No servidor de 64 GB de RAM, o processo de cópia agora é interrompido ou limitado a alguns MBs. No servidor de 32 GB de RAM está tudo bem.
• No servidor de 64 GB de RAM, posso resolver o problema por um breve momento, forçando o cache com "sync; echo 3> /proc/sys/vm/drop_caches". Mas é claro que o buffer começa a crescer novamente instantaneamente e o problema ocorre novamente.

Conclusão:

O problema tem algo a ver com a segunda CPU ou com a quantidade total de memória. Tenho a “sensação” de que o problema pode ser que cada CPU tem sua própria RAM de 32 GB e o processo de cópia é executado apenas na CPU. Então, finalmente, o processo de cópia aumentou o buffer/cache para quase 32 GB ou para a memória não usada da outra CPU e então o Linux pensa: ei, ainda há memória, então vamos aumentar ainda mais o buffer, mas o hardware abaixo não consegue acessar a memória, ou algo assim assim.

Alguém tem uma idéia ou uma solução?Claro que posso usar dd com flag direta, mas isso não resolve o problema, pois também há acesso externo via samba e assim por diante.

EDITAR1:

Aqui também o /proc/zoneinfo do servidor de 64GB de RAM: 1.http://pastebin.com/uSnpQbeD(antes do dd começar) 2.http://pastebin.com/18YVTfdb(quando dd para de funcionar)

EDITAR2:

• Configurações da VM:http://pastebin.com/U9E9KkFS
• /proc/sys/vm/zone_reclaim_mode estava no servidor 0 de 32 GB de RAM e no servidor 1 de 64 GB de RAM. Nunca toco nesses valores. O instalador os definiu. Alterei a temperatura para 0 e tentei novamente o teste. Agora toda a memória é usada para buffer e cache. Portanto, parece ótimo e parecido com o outro servidor. Mas então ele instantaneamente começa a trocar com velocidade total... Eu configurei a troca para 0. Isso ajuda, mas ainda troca alguns MB por segundo. E aumenta os buffers a cada segundo. Então ele não troca o buffer, ele troca a memória do vms para conseguir mais memória para aumentar os buffers... uma loucura. Mas talvez isso seja normal!?

EDITAR3:

/proc/buddyinfo e numactl --hardware: http://pastebin.com/0PmXxxin

RESULTADO FINAL

• /proc/sys/vm/zone_reclaim_mode é com certeza o caminho técnico correto, mas a máquina não funcionou muito bem depois disso. Por exemplo: se eu copiar um disco Linux, use agora 100% do mem livre para buffer (não como antes, apenas XGB e depois pare). Mas no momento em que o último mem livre foi usado para buffer, o Linux começa a trocar a memória VM e aumenta a quantidade total de buffer e caches. A troca normalmente não é necessária no meu sistema, portanto a memória swap está no mesmo disco que algumas VMs. No resultado, se fizer um backup desses vms linux, gravo o swap ao mesmo tempo que leio o disco para o backup. Portanto, é ruim trocar o vms, mas é ainda pior que o linux destrua minha velocidade de leitura de backup ... Portanto, a configuração de /proc/sys/vm/zone_reclaim_mode como 0 não resolve todo o problema ... atualmente corro em um exibir um script que sincroniza e libera o cache a cada 10 segundos ... não é legal, mas funciona muito melhor para mim. Não tenho servidor web ou servidor de arquivos normal no sistema. Eu só executo vms, faço backups e armazeno backups via samba. Eu não gosto da solução.

Answer 1

O comportamento que você está vendo se deve à maneira como o Linux aloca memória em um sistema NUMA.

Estou assumindo (sem saber) que o sistema de 32GB não é numa, ou não é numa o suficiente para o Linux se importar.

O comportamento de como lidar com os numa é ditado pela /proc/sys/vm/zone_reclaim_modeopção. Por padrão, o Linux detectará se você está usando um sistema numa e alterará os sinalizadores de recuperação se achar que proporcionaria melhor desempenho.

A memória é dividida em zonas, num sistema existe uma zona para o primeiro soquete da CPU e uma zona para o segundo. Eles aparecem como node0e node1. Você pode vê-los se você for um gato /proc/buddyinfo.

Quando o modo de recuperação de zona é definido como 1, a alocação do primeiro soquete da CPU fará com que a recuperação ocorra na zona de memória associada a essa CPU, isso ocorre porque é mais eficiente em termos de desempenho recuperar de um nó numa local. Nesse sentido, recuperar é descartar páginas, como limpar o cache ou trocar coisas naquele nó.

Definir o valor como 0 faz com que nenhuma recuperação ocorra se a zona estiver sendo preenchida, em vez disso, alocando nas zonas numa estrangeiras para a memória. Isso tem o custo de um breve bloqueio da outra CPU para obter acesso exclusivo a essa zona de memória.

Mas então ele começa a trocar instantaneamente! após alguns segundos: Mem: 66004536k no total, 65733796k usados, 270740k livres, 34250384k buffers Troca: 10239992k no total, 1178820k usados, 9061172k livres, 91388k em cache

O comportamento de troca e quando trocar é determinado por alguns fatores, sendo um deles o quão ativas são as páginas que foram alocadas aos aplicativos. Se não estiverem muito ativos, serão trocados em favor do trabalho mais movimentado que ocorre no cache. Presumo que as páginas nas suas VMs não sejam ativadas com muita frequência.