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.