Usamos o rsync para fazer backup de servidores.

Infelizmente, a rede de alguns servidores está lenta.

Leva até cinco minutos para o rsync detectar, que nada mudou em grandes diretórios. Essas enormes árvores de diretórios contêm muitos arquivos pequenos (cerca de 80k).

Eu acho que os clientes rsync enviam dados para cada um dos arquivos de 80k.

Como a rede é lenta, gostaria de evitar o envio de informações de 80k vezes sobre cada arquivo.

Existe uma maneira de dizer ao rsync para fazer uma soma de hash de uma árvore de subdiretórios?

Dessa forma, o cliente rsync enviaria apenas alguns bytes para uma grande árvore de diretórios.

Atualizar

Até agora minha estratégia é usar rsync. Mas se uma ferramenta diferente se encaixar melhor aqui, eu posso mudar. Ambos (servidor e cliente) estão sob meu controle.

Update2

Existem 80k arquivos em uma árvore de diretórios . Cada diretório único não possui mais de 2k arquivos ou subdiretórios

Update3

Detalhes sobre a lentidão da rede:

time ssh einswp 'cd attachments/200 && ls -lLR' >/tmp/list
real    0m2.645s

Tamanho do arquivo tmp / list: 2MByte

time scp einswp:/tmp/list tmp/
real    0m2.821s

Conclusão: scp tem a mesma velocidade (sem surpresa)

time scp einswp:tmp/100MB tmp/
real    1m24.049s

Velocidade: 1.2MB / s

Alguns pontos não relacionados:

80K são muitos arquivos.

80.000 arquivos em um diretório? Nenhum sistema operacional ou aplicativo lida com essa situação muito bem por padrão. Você acabou de perceber esse problema com o rsync.

Verifique sua versão do rsync

O rsync moderno lida com diretórios grandes muito melhor do que no passado. Verifique se você está usando a versão mais recente.

Até o antigo rsync lida com diretórios grandes razoavelmente bem com links de alta latência ... mas os arquivos de 80k não são grandes ... é enorme!

Dito isto, o uso da memória do rsync é diretamente proporcional ao número de arquivos em uma árvore. Diretórios grandes ocupam uma grande quantidade de RAM. A lentidão pode ser devido à falta de RAM em ambos os lados. Faça um teste enquanto assiste ao uso da memória. O Linux usa qualquer RAM restante como cache de disco; portanto, se você estiver com pouca memória RAM, haverá menos cache de disco. Se você ficar sem memória RAM e o sistema começar a usar swap, o desempenho será muito ruim.

Verifique se --checksum não está sendo usado

--checksum(ou -c) requer a leitura de cada bloco de cada arquivo. Você provavelmente pode se dar bem com o comportamento padrão de apenas ler os tempos de modificação (armazenados no inode).

Divida o trabalho em pequenos lotes.

Existem alguns projetos como o Gigasync que " cortam a carga de trabalho usando o perl para repetir a árvore de diretórios, criando pequenas listas de arquivos para transferir com o rsync".

A varredura extra de diretório será uma grande quantidade de sobrecarga, mas talvez seja uma vitória líquida.

Os padrões do SO não são criados para esta situação.

Se você estiver usando Linux / FreeBSD / etc com todos os padrões, o desempenho será terrível para todos os seus aplicativos. Os padrões assumem diretórios menores para não desperdiçar RAM em caches de grandes dimensões.

Ajuste seu sistema de arquivos para lidar melhor com diretórios grandes: Os tamanhos de pastas grandes diminuem o desempenho das E / S?

Veja o "cache namei"

Os sistemas operacionais do tipo BSD têm um cache que acelera a procura de um nome para o inode (o cache "namei"). Há um cache namei para cada diretório. Se for muito pequeno, é mais um obstáculo do que uma otimização. Como o rsync está executando um lstat () em cada arquivo, o inode está sendo acessado para todos os arquivos de 80k. Isso pode estar sobrecarregando o cache. Pesquise como ajustar o desempenho do diretório de arquivos no seu sistema.

Considere um sistema de arquivos diferente

O XFS foi projetado para lidar com diretórios maiores. Consulte Sistema de arquivos grande número de arquivos em um único diretório

Talvez 5 minutos seja o melhor que você pode fazer.

Considere calcular quantos blocos de disco estão sendo lidos e calcule com que rapidez você deve esperar que o hardware consiga ler esses blocos.

Talvez suas expectativas sejam muito altas. Considere quantos blocos de disco devem ser lidos para executar um rsync sem arquivos alterados: cada servidor precisará ler o diretório e ler um inode por arquivo. Vamos supor que nada seja armazenado em cache porque, bem, arquivos de 80k provavelmente esgotaram seu cache. Digamos que são 80k blocos para manter a matemática simples. São cerca de 40 milhões de dados, que devem ser lidos em alguns segundos. No entanto, se for necessário haver uma busca de disco entre cada bloco, isso poderá levar muito mais tempo.

Então, você precisará ler cerca de 80.000 blocos de disco. Quão rápido o seu disco rígido pode fazer isso? Considerando que esta é uma E / S aleatória, e não uma leitura linear longa, 5 minutos podem ser bastante excelentes. Isso é 1 / (80000/600), ou um disco é lido a cada 7,5ms. Isso é rápido ou lento para o seu disco rígido? Depende do modelo.

Referência contra algo semelhante

Outra maneira de pensar sobre isso é isso. Se nenhum arquivo foi alterado, ls -Llrrealiza a mesma quantidade de atividade do disco, mas nunca lê nenhum dado do arquivo (apenas metadados). O tempo ls -Llrnecessário para executar é o seu limite superior.

• O rsync (sem arquivos alterados) é significativamente mais lento que ls -Llr? Em seguida, as opções que você está usando para o rsync podem ser melhoradas. Talvez -cesteja ativado ou algum outro sinalizador que leia mais do que apenas diretórios e metadados (dados do inode).

• O rsync (sem arquivos alterados) é quase tão rápido quanto ls -Llr? Então você ajustou o rsync da melhor maneira possível. Você precisa ajustar o sistema operacional, adicionar RAM, obter unidades mais rápidas, alterar sistemas de arquivos etc.

Fale com seus desenvolvedores

Arquivos de 80k é apenas um design ruim. Muito poucos sistemas de arquivos e ferramentas de sistema lidam muito bem com diretórios tão grandes. Se os nomes dos arquivos forem abcdefg.txt, considere armazená-los em abdc / abcdefg.txt (observe a repetição). Isso divide os diretórios em outros menores, mas não requer uma grande alteração no código.

Além disso ... considere usar um banco de dados. Se você tiver 80k arquivos em um diretório, talvez seus desenvolvedores estejam contornando o fato de que realmente desejam um banco de dados. MariaDB ou MySQL ou PostgreSQL seria uma opção muito melhor para armazenar grandes quantidades de dados.

Ei, o que há de errado em 5 minutos?

Por fim, 5 minutos são realmente tão ruins? Se você executar esse backup uma vez por dia, 5 minutos não serão muito demorados. Sim, eu amo velocidade. No entanto, se 5 minutos forem "bons o suficiente" para seus clientes, serão bons o suficiente para você. Se você não possui um SLA por escrito, que tal uma discussão informal com seus usuários para descobrir com que rapidez eles esperam que os backups durem.

Suponho que você não fez essa pergunta se não havia necessidade de melhorar o desempenho. No entanto, se seus clientes estiverem satisfeitos com 5 minutos, declare a vitória e passe para outros projetos que precisam de seus esforços.

Atualização: Após algumas discussões, determinamos que o gargalo é a rede. Vou recomendar duas coisas antes de desistir :-).

• Tente espremer mais largura de banda do tubo com compressão. No entanto, a compactação requer mais CPU; portanto, se sua CPU estiver sobrecarregada, poderá piorar o desempenho. Tente rsync com e sem -ze configure seu ssh com e sem compactação. Cronometre todas as 4 combinações para ver se alguma delas apresenta um desempenho significativamente melhor que outras.
• Assista ao tráfego da rede para ver se há alguma pausa. Se houver pausas, você poderá encontrar o que as está causando e otimizar lá. Se o rsync estiver sempre enviando, você estará realmente no seu limite. Suas escolhas são:
  • uma rede mais rápida
  • algo diferente de rsync
  • aproxime a origem e o destino. Se você não pode fazer isso, pode sincronizar novamente com uma máquina local e depois sincronizar com o destino real? Pode haver benefícios em fazer isso se o sistema precisar ficar inativo durante o rsync inicial.

Não, isso não é possível com o rsync e seria bastante ineficiente em outro aspecto:

Normalmente, rsyncapenas compara datas de modificação e tamanhos de arquivo. Sua abordagem forçaria a leitura e soma de verificação do conteúdo de todos os arquivos duas vezes (no sistema local e remoto) para encontrar diretórios alterados.

Para sincronizar um grande número de arquivos (onde pouco mudou), também vale a pena definir noatimeas partições de origem e destino. Isso economiza o tempo de acesso de gravação no disco para cada arquivo inalterado.

Você também pode tentar lsyncd, que só será sincronizado quando alterações forem detectadas no sistema de arquivos e apenas nos subdiretórios alterados. Eu tenho usado para diretórios com até dois milhões de arquivos em um servidor decente.

Use rsync no modo daemon no final do servidor para acelerar o processo de listagem / soma de verificação:

• Daemon Rsync: é realmente útil?
• http://giantdorks.org/alain/achieve-faster-file-transfer-times-by-running-rsync-as-a-daemon/

Observe que não é criptografado, mas pode ser encapsulado sem perder a melhoria no desempenho da listagem.

Também fazer com que o rsync faça compressão em vez do ssh deve melhorar o desempenho.