Não, o comportamento real é imprevisível, mas é provável que as várias instâncias tentem copiar o mesmo arquivo ao mesmo tempo e a largura de banda seja desperdiçada, e coisas ruins podem acontecer.
No entanto, o uso inteligente de --include e --exclude pode ser útil aqui:
rsync -avP \
--include '*/' --include '[a-g]*' --exclude '*' \
source.host:path/to/source/ path/to/dest/
Este comando só enviará arquivos que começam com as letras a to g . Você pode configurar transferências paralelas para as outras partes do alfabeto.
Finalmente, assim que todas as transferências estiverem completas, você deve rodar o seu comando original rsync novamente (note que eu deixei o --remove-source-files do meu comando) para garantir que qualquer estranheza aconteceu e todos os arquivos que seus filtros originais perderam (arquivos de pontos, talvez?) também foram transferidos.
Por acaso, sempre coloque a barra final nos diretórios de origem e de destino (por exemplo, path/to/dest/ ) ou rsync pode não fazer o que você espera!
No entanto , o rsync não é a maneira mais eficiente de replicar arquivos pela primeira vez, especialmente quando a latência é alta (destina-se principalmente à atualização subsequente).
Você seria muito melhor usar tar para transmitir os dados para ssh :
ssh source.host tar -C path/to/source/ cfj - . | tar -C path/to/dest/ xfj -
Isto irá empacotar e comprimir os dados em um fluxo contínuo, canalizá-los através do seu túnel ssh , de volta para tar em sua extremidade local e expandir de volta para arquivos em um único comando e sem o arquivo tar alguma vez tocando o disco.
O lado negativo é que não é facilmente reiniciável se a conexão cair.
Tar também tem uma opção --exclude (mas não --include ), então você pode paralelizar os fluxos de maneira similar, se necessário. Novamente, você provavelmente deve terminar com um rsync para verificar a transferência.
Além disso: A "natureza do TCP" não é o problema aqui. O TCP usa um esquema de janela deslizante que deve saturar o link em qualquer latência normal, e há botões para girar se ele não funcionar t.
A natureza do rsync, no entanto, é que ele deve fazer algumas conversas sobre cada arquivo antes de transferi-lo, e a latência vai doer aqui (embora a implementação use pipelining para minimizar isso).
Se você não está saturando seu link, então a primeira coisa a tentar é tirar o rsync da equação ( scp de um arquivo adequadamente grande serve). Se isso ainda não for feito, verifique o uso da CPU: a compactação e a criptografia podem ser o gargalo. Se a transferência de dados simples via Netcat (ou FTP antigo) não puder fazê-lo, talvez seja necessário ajustar o TCP. Além disso, verifique se há perda de pacotes com ping , pois isso realmente estragará o TCP. Finalmente, pode ser que o link mais lento na cadeia não seja seu.