Estou tentando transferir cerca de 100 mil arquivos, totalizando 90 GB. No momento estou usando o daemon rsync, mas é lento em 3,4 MB/s e preciso fazer isso várias vezes. Estou me perguntando quais opções eu tenho que maximizariam uma conexão de 100 mbit pela Internet e seriam muito confiáveis.
Responder1
Você considerouRede de tênis? Com grandes conjuntos de dados, o envio noturno costuma ser mais rápido e mais barato do que a transferência pela Internet.
Responder2
Como? Ou TL;DR
O método mais rápido que encontrei é uma combinação de tare .mbufferssh
Por exemplo:
tar zcf - bigfile.m4p | mbuffer -s 1K -m 512 | ssh otherhost "tar zxf -"
Usando isso, consegui transferências sustentadas de rede local acima de 950 Mb/s em links de 1 Gb. Substitua os caminhos em cada comando tar para serem apropriados ao que você está transferindo.
Por que? amortecedor!
O maior gargalo na transferência de arquivos grandes em uma rede é, de longe, a E/S de disco. A resposta para isso é mbufferou buffer. Eles são muito semelhantes, mas mbuffertêm algumas vantagens. O tamanho do buffer padrão é 2 MB para mbuffere 1 MB para arquivos buffer. Buffers maiores têm maior probabilidade de nunca ficarem vazios. Escolher um tamanho de bloco que seja o menor múltiplo comum do tamanho do bloco nativo no sistema de arquivos de destino e no sistema de arquivos de destino proporcionará o melhor desempenho.
Buffer é o que faztodosa diferença!Use-o se você tiver! Se você não tem, pegue! Usar (m}?buffermais qualquer coisa é melhor do que qualquer coisa por si só. é quase literalmente uma panacéia para transferências lentas de arquivos em rede.
Se você estiver transferindo vários arquivos, use tar-os para "agrupá-los" em um único fluxo de dados. Se for um único arquivo, você pode usar cato redirecionamento de E/S. A sobrecarga de tarvs. caté estatisticamente insignificante, então eu sempre uso tar(ou zfs -sendonde posso), a menos que já seja umtarball. Nenhum deles tem garantia de fornecer metadados (e, em particular, catnão fornecerá). Se você quiser metadados, deixarei isso como um exercício para você.
Finalmente, usar sshcomo mecanismo de transporte é seguro e acarreta muito pouca sobrecarga. Novamente, a sobrecarga de sshvs. ncé estatisticamente insignificante.
Responder3
Você mencionou "rsync", então presumo que você esteja usando Linux:
Por que você não cria um arquivo tar ou tar.gz? O tempo de transferência de rede de um arquivo grande é mais rápido do que muitos arquivos pequenos. Você pode até comprimi-lo se desejar ...
Alcatrão sem compressão:
No servidor de origem:
tar -cf file.tar /path/to/files/
Então, no lado receptor:
cd /path/to/files/
tar -xf /path/to/file.tar
Alcatrão com compressão:
No servidor de origem:
tar -czf file.tar.gz /path/to/files/
Então, no lado receptor:
cd /path/to/files/
tar -xzf /path/to/file.tar.gz
Você simplesmente usaria o rsync para fazer a transferência real dos arquivos (tar|tar.gz).
Responder4
Você pode usar várias opções de compactação do rsync.
-z, --compress compress file data during the transfer
--compress-level=NUM explicitly set compression level
--skip-compress=LIST skip compressing files with suffix in LIST
a taxa de compactação para arquivos binários é muito baixa, então você pode pular esses arquivos usando --skip-compress, por exemplo, iso, tarballs já arquivados e compactados, etc.