Em um sistema com 64 GB de mem, o buffer do Linux é executado completamente enquanto copia com dd para dev null e io para até drop_caches manuais

Em um sistema com 64 GB de mem, o buffer do Linux é executado completamente enquanto copia com dd para dev null e io para até drop_caches manuais

Estou executando um servidor com software Linux RAID 10. É um sistema de CPU dupla com 64 GB de RAM. 2x16GB dimms relacionados a cada uma das CPUs. Quero usar o dd para fazer backup de máquinas virtuais kvm e me deparar com um sério problema de io. Primeiro pensei que estivesse relacionado ao ataque, mas é um problema de gerenciamento de memória do Linux. Aqui está um exemplo:

  1. A memória está boa: https://i.stack.imgur.com/NbL60.jpg
  2. Eu começo dd: https://i.stack.imgur.com/kEPN2.jpg
  3. Você vê também que nmon mostra o acesso ao disco: https://i.stack.imgur.com/Njcf5.jpg
  4. Depois de um tempo, os "buffers" ficam grandes e o progresso da cópia para https://i.stack.imgur.com/HCefI.jpg
  5. Aqui está a informação: https://i.stack.imgur.com/KR0CE.jpg
  6. Aqui a saída do dd: https://i.stack.imgur.com/BHjnR.jpg
  7. Posso resolver manualmente o problema temporariamente e forçar a eliminação do cache: "sync; echo 3 > /proc/sys/vm/drop_caches"
  8. A chamada leva alguns segundos e instantaneamente depois disso a velocidade do dd atinge o nível normal. Claro que posso fazer um cronjob a cada minuto ou algo assim, mas isso não é uma solução real. https://i.stack.imgur.com/zIDRz.jpg https://i.stack.imgur.com/fO8NV.jpg

Alguém tem uma solução ou uma dica de configuração? Aqui também está meu sysctl, mas todos os valores são padrões do centos: https://i.stack.imgur.com/ZQBNG.jpg

Editar1

Eu faço outro teste e faço um dd no disco em vez de/dev/null. Desta vez também em um comando sem pv. Portanto, é apenas um processo.dd if=/dev/vg_main_vms/AppServer_System of=AppServer_System bs=4M

  1. Começa lendo sem escrever (o alvo não está nos mesmos discos) https://i.stack.imgur.com/jJg5x.jpg
  2. Depois de um tempo a escrita começa e a leitura fica mais lenta https://i.stack.imgur.com/lcgW6.jpg
  3. Depois disso chega a hora de escrever: https://i.stack.imgur.com/5FhG4.jpg
  4. Agora começa o problema principal. O processo de cópia ficou lento para menos de 1 MB e nada aconteceu: https://i.stack.imgur.com/YfCXc.jpg
  5. O processo dd agora precisa de 100% do tempo de CPU (1 núcleo) https://i.stack.imgur.com/IZn1N.jpg
  6. E, novamente, posso resolver manualmente o problema temporariamente e forçar a eliminação do cache: sync; echo 3 > /proc/sys/vm/drop_caches. Depois disso o mesmo jogo começa novamente...

Editar2

Para o dd local, posso contornar com o parâmetro iflag=direct e oflag=direct. Mas esta não é uma solução universal porque também há outro acesso a arquivos, como copiar arquivos para os compartilhamentos locais do samba de uma VM e não posso usar esses parâmetros. Deve haver um ajuste nas regras de cache de arquivos do sistema, porque não pode ser normal que você não consiga copiar arquivos grandes sem esses problemas.

Responder1

Apenas um palpite. Seu problema pode ser uma grande descarga de páginas sujas. Tente configurar /etc/sysctl.conf como:

# vm.dirty_background_ratio contains 10, which is a percentage of total system memory, the 
# number of pages at which the pdflush background writeback daemon will start writing out 
# dirty data. However, for fast RAID based disk system this may cause large flushes of dirty
# memory pages. If you increase this value from 10 to 20 (a large value) will result into 
# less frequent flushes:
vm.dirty_background_ratio = 1

# The value 40 is a percentage of total system memory, the number of pages at which a process
# which is generating disk writes will itself start writing out dirty data. This is nothing
# but the ratio at which dirty pages created by application disk writes will be flushed out
# to disk. A value of 40 mean that data will be written into system memory until the file 
# system cache has a size of 40% of the server's RAM. So if you've 12GB ram, data will be
# written into system memory until the file system cache has a size of 4.8G. You change the
# dirty ratio as follows:
vm.dirty_ratio = 1

Então faça sysctl -ppara recarregar, solte os caches novamente ( echo 3 > /proc/sys/vm/drop_caches).

informação relacionada