Início / computer / Perguntas / 1600336
Accepted
Thorsten Schöning
Asked: 2020-11-08 06:54:13 +0800 CST

Por que o RSYNC usa dois processos de leitura com arquivos diferentes no meu destino de backup?

  • 772

Fundo

Eu tenho um servidor que hospeda máquinas virtuais e um NAS Synology DS1512+ mais antigo usado como destino de backup para essas máquinas virtuais. O servidor usa ZFS, cria instantâneos e transfere os arquivos dos instantâneos para o NAS. O NAS usa BTRFS com compactação habilitada e também suporta instantâneos. o objetivo final seria que o servidor realmente apenas enviasse DELTAs usando RSYNC para minimizar a quantidade de dados alterados recebidos pelo NAS e fazer uso eficiente de instantâneos nele também.

Problema

Usar RSYNC com DELTAs não funciona no meu caso, porque transferir os dados simplesmente leva muito tempo . Quando o RSYNC é usado com --inplace --whole-file, os dados levam aproximadamente 2 horas para serem transferidos. Ao remover --whole-filepara usar DELTAs, o mesmo processo de backup demora muito mais, muitas vezes eu matei o processo depois de já executar mais de 12 horas. Por motivos históricos, preciso encaixar diferentes backups em janelas de tempo muito menores.

O único gargalo que faz sentido é o NAS, porque o servidor é muito mais poderoso e fica ocioso na maior parte do tempo. O NAS OTOH tem uma carga bastante alta na CPU e E/S durante o backup. No entanto, os números também não são tão ruins, é apenas que eles são mais ruins do que quando se usa --whole-file. Com isso, o NAS simplesmente grava ~100+ MiB/s, enquanto com DELTAs ele lê mais devagar na maioria das vezes, abrangendo de ~50 a 100 MiB/s. Eu pensei que a quantidade de dados para NÃO gravar por causa dos DELTAs superaria facilmente o fato do NAS mais lento, mas esse não parece ser o caso. E a quantidade alterada de dados nas VMs não é muito alta principalmente.

Observação

O que reconheci no NAS foi que o RSYNC parece processar dois arquivos ao mesmo tempo em algum momento. Isso se parece com alguma leitura antecipada ou semelhante:

root@amds1512-01:~# lsof | grep [d]asi_
rsync   6883   root  cwd    DIR   0,33        290   259 /volume1/[...]
rsync   6883   root    0r   REG   0,33 2142633984   580 /volume1/[...]/[...]-s024.vmdk
rsync   6884   root  cwd    DIR   0,33        290   259 /volume1/[...]
rsync   6884   root    1r   REG   0,33 2143748096   579 /volume1/[...]/[...]-s023.vmdk
rsync   6884   root    3w   REG   0,33 2143748096   579 /volume1/[...]/[...]-s023.vmdk

O HTOP mostra claramente que ambas as instâncias de RSYNC são lidas. Apenas ignore os outros processos RSYNC, eles não estão relacionados e o problema ainda persiste mesmo quando um backup é executado exclusivamente.

Captura de tela HTOP

Perguntas

Então, qual é o propósito desses dois RSYNCs em execução com arquivos diferentes no destino de backup? Existe alguma maneira de dizer ao RSYNC para processar apenas um arquivo após o outro?

Isso pode aumentar o tempo de processamento geral com menos carga simultânea. Não consegui encontrar nada como ler adiante ou semelhante na página de manual. Se fizer alguma diferença, as seguintes são as opções usadas:

--owner \
--numeric-ids \
--compress-level=0 \
--group \
--perms \
--rsh=rsh \
--devices \
--hard-links \
--inplace \
--links \
--recursive \
--times \
--delete \
--delete-during \
--delete-excluded \
--rsync-path=[...] \
--specials

Obrigado!

linux backup

1 respostas

  1. Best Answer

    Dê uma olhada em Como funciona o Rsync . Especificamente, existe um processo gerador e um processo emissor que funcionam como um pipeline. O remetente lê o arquivo para enviar ao controle remoto. O gerador é responsável por gerar a lista de arquivos a serem enviados, e também “são criados checksums de bloco para o arquivo base e enviados ao remetente imediatamente após o número de índice do arquivo”.

    Isso definitivamente parece que tem o potencial de causar thrashing no sistema de arquivos se você estiver usando --inplacepara enviar vários arquivos grandes e não tiver RAM suficiente disponível para o kernel manter dois arquivos consecutivos em cache .

    Como teste, você pode tentar transferir arquivos individuais rsync --inpacee ver se o desempenho é significativamente melhor. (Algo como for i in *.vmdk; do rsync [...]; done.) Isso deve ajudar a determinar se ter dois leitores separados está realmente causando o problema de desempenho.

    Se vários leitores estiverem causando o problema de desempenho, uma rota possível seria melhorar a capacidade do kernel de armazenar em cache as leituras, tornando mais RAM disponível para o kernel do host ou tornando seus arquivos vmdk individuais menores.

    Infelizmente, não vejo nenhuma maneira óbvia de alterar o comportamento do pipeline do gerador/remetente no rsync, exceto escrever seu próprio script para chamar o rsync uma vez para cada arquivo. Você pode querer perguntar sobre isso na lista de discussão rsync .

    • 2

relate perguntas