Em um sistema com 64GB mem, o Linux Buffer fica cheio enquanto copia com dd para dev null e io pára até o manual drop_caches

Question

Estou executando um servidor com o software linux RAID 10. É um sistema de CPU dual com 64GB Ram. 2x16GB dimmers relacionados a cada uma das CPUs. Eu quero usar o dd para fazer backup de máquinas virtuais kvm e executar um problema sério. Primeiro, pensei que está relacionado ao ataque, mas é um problema do gerenciamento de memória do Linux. Aqui está um exemplo:

1. A memória está bem: link
2. eu inicio o dd: link
3. Você também vê nmon mostra o acesso ao disco: link
4. Depois de um tempo, os "buffers" são grandes e o progresso da cópia é interrompido link
5. Aqui está o meminfo: link
6. Aqui a saída dd: link
7. Eu posso resolver manualmente o problema e forçar a queda do cache: "sync; echo 3 > / proc / sys / vm / drop_caches"
8. A chamada precisa de alguns segundos e, instantaneamente, a velocidade dd alcança o nível normal. Claro que eu posso um cronjob cada minuto ou coisas assim, mas isso não é uma solução real. link link

Alguém tem uma solução ou uma dica de configuração? Aqui está também o meu sysctl mas todos os valores são padrões centos: link

Editar1

Eu faço um outro teste e faço um dd para o disco em vez de / dev / null. Desta vez também em um comando sem pv. Então é o único processo. dd if=/dev/vg_main_vms/AppServer_System of=AppServer_System bs=4M

1. Começa lendo sem escrever (o destino não está nos mesmos discos) link
2. Depois de um tempo a escrita começa e a leitura diminui link
3. Depois disso, chega a hora da escrita: link
4. Agora começa o problema principal. O processo de cópia abrandar para menos de 1mb e nada aconteceu: link
5. O processo dd agora precisa de 100% de tempo de CPU (1 núcleo) link
6. E mais uma vez eu posso resolver manualmente o problema e forçar a queda do cache: %código%. Depois disso, o mesmo jogo começa de novo ...

Editar2

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

    

Answer 1

Apenas um palpite. Seu problema pode ser uma grande descarga de página suja. Tente configurar o /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

Em seguida, use sysctl -p para recarregar, descartar os caches novamente ( echo 3 > /proc/sys/vm/drop_caches ).