O cache de páginas do Linux reduz o IO no servidor de cpu duplo com 64 GB de RAM

Question

Eu tenho um problema enorme com o cache de páginas do linux que retarda o IO. Por exemplo, se eu copiar uma partição lvm com o dd, o linux armazenará 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 pára e diminui para alguns mbs ou até mesmo 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 o destino.

Em detalhes:

• Existem dois servidores quase idênticos. Ambos rodando o CentOS 6.5 com o mesmo kernel. Eles têm os mesmos discos, a mesma configuração, o mesmo hardware, o mesmo em todos os aspectos. A única diferença é que um servidor tem 2 CPUs e 64 GB de RAM e o outro 1 CPU e 32 GB de RAM.
• Veja também uma imagem do seguinte processo de cópia: link
• Aqui 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: link
• Inicie a cópia com o dd ou outro programa de cópia do sistema de arquivos.
• Buffer ou cache começam a ser preenchidos. Tudo está bem.
• O buffer ou o cache atinge um número máximo (em um servidor RAM de 64 GB, um valor como 32 GB ou 17 GB; no servidor ram de 32 GB, toda a memória livre)
• Em um servidor de 64 GB, o processo de cópia agora é interrompido ou limitado a alguns mbs. No servidor de 32 GB, tudo está bem.
• No servidor RAM de 64GB, posso resolver o problema por um curto momento forçando o cache com "sync; echo 3 > / proc / sys / vm / drop_caches". Mas é claro que o buffer começa a crescer novamente e o problema ocorre novamente.

Conclusão:

O problema tem algo a ver com o segundo cpu ou com a quantidade total de memória. Eu tenho o "sentimento" de que o problema pode ser, que cada CPU tem seu próprio 32GB de RAM e o processo de cópia em execução apenas no cpu. Então, finalmente, o processo de cópia acarreta o buffer / cache para quase 32GB ou para a memória não usada da outra cpu e então o Linux acha que ainda há memória, então vamos aumentar o buffer ainda mais, mas o hardware abaixo não consegue acessar a memória, ou algo Curtiu isso.

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

EDIT1:

Aqui também o / proc / zoneinfo do servidor RAM de 64GB: 1. link (antes do dd iniciar) 2. link (quando o dd parar de funcionar)

EDIT2:

• Configurações da VM: link
• / proc / sys / vm / zone_reclaim_mode estava no servidor ram de 32 GB 0 e no servidor de ram de 64 GB 1. Nunca toquei nesses valores. O instalador configurou estes. Eu temp alterou para 0 e tente novamente o teste. Agora toda a memória é usada para buffer e cache. Então, parece ótimo e como o outro servidor. Mas então ele instantaneamente começa a trocar com a velocidade máxima ... Eu configurei a swapiness para 0. Isso ajuda, mas ainda troca alguns mb por segundo. E aumenta os buffers a cada segundo. Então não troque o buffer, troque a memória do vms para obter mais memória para aumentar os buffers ... doido. Mas talvez isso seja normal!?

EDIT3:

/ proc / buddyinfo e numactl --hardware: link

RESULTADO FINAL

• / proc / sys / vm / zone_reclaim_mode é certamente o caminho técnico, mas o maschine não funcionou muito bem depois dele. 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 segundo em que a última mem livre foi usada 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, então a memória swap está no mesmo disco que algumas vms. No resultado, se fizer um backup dessas vms linux, escreva a troca ao mesmo tempo que leio do disco para o backup. Então é ruim para trocar o vms, mas é ainda pior que o Linux destruir minha velocidade de leitura de backup ... Então a configuração de / proc / sys / vm / zone_reclaim_mode para 0 não resolve o problema completo ... atualmente eu corro em um tela um script que sincroniza e armazena cache a cada 10 segundos ... não é legal, mas funciona muito melhor para mim. Eu 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 é uma, ou não é o suficiente para o Linux se importar.

O comportamento de como lidar com uma é ditado pela opção /proc/sys/vm/zone_reclaim_mode . Por padrão, o Linux detectará se você está usando um sistema num e mudará os sinalizadores de recuperação se achar que isso daria um melhor desempenho.

A memória é dividida em zonas, em um sistema há uma zona para o primeiro soquete de CPU e uma zona para o segundo. Eles aparecem como node0 e node1 . Você pode vê-los se você cat /proc/buddyinfo .

Quando o modo de recuperação da 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, porque é mais eficiente em termos de desempenho recuperar de um local numa nó. Reclamar nesse sentido é derrubar páginas como limpar o cache ou trocar coisas nesse nó.

Definir o valor como 0 faz com que não ocorram reclamações se a zona estiver sendo preenchida, em vez disso, alocando as zonas da parte estrangeira para a memória. Isso tem um custo de bloqueio de bloqueio da outra CPU para obter acesso exclusivo a essa zona de memória.

But then it instantly start swaping! after a few secouns: Mem: 66004536k total, 65733796k used, 270740k free, 34250384k buffers Swap: 10239992k total, 1178820k used, 9061172k free, 91388k cached

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