Por que meu rsync é tão lento?

Meu laptop e minha estação de trabalho estão conectados a um comutador Gigabit. Ambos estão executando o Linux. Mas quando copio arquivos rsync, ele apresenta um desempenho ruim.

Eu recebo cerca de 22 MB / s. Teoricamente, não deveria obter cerca de 125 MB / s? Qual é o fator limitante aqui?

Edição: Realizei alguns experimentos.

Grave o desempenho no laptop

O laptop possui um sistema de arquivos xfs com criptografia de disco completa. Ele usa o aes-cbc-essiv:sha256modo de cifra com comprimento de chave de 256 bits. O desempenho de gravação em disco é de 58,8 MB / s .

iblue@nerdpol:~$ LANG=C dd if=/dev/zero of=test.img bs=1M count=1024
1073741824 Bytes (1.1 GB) copied, 18.2735 s, 58.8 MB/s

Leia o desempenho na estação de trabalho

Os arquivos que eu copiei estão em um software RAID-5 com mais de 5 HDDs. No topo do ataque está um lvm. O volume em si é criptografado com a mesma cifra. A estação de trabalho possui uma CPU FX-8150 que possui um conjunto de instruções AES-NI nativo que acelera a criptografia. O desempenho da leitura do disco é de 256 MB / s (o cache estava frio).

iblue@raven:/mnt/bytemachine/imgs$ dd if=backup-1333796266.tar.bz2 of=/dev/null bs=1M
10213172008 bytes (10 GB) copied, 39.8882 s, 256 MB/s

Desempenho de rede

Corri o iperf entre os dois clientes. O desempenho da rede é de 939 Mbit / s

iblue@raven $ iperf -c 94.135.XXX
------------------------------------------------------------
Client connecting to 94.135.XXX, TCP port 5001
TCP window size: 23.2 KByte (default)
------------------------------------------------------------
[  3] local 94.135.XXX port 59385 connected with 94.135.YYY port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.09 GBytes   939 Mbits/sec

Outra maneira de reduzir o alto uso da CPU, mas ainda manter a funcionalidade do rsync, é mudar de rsync / SSH para rsync / NFS. Você pode exportar os caminhos dos quais deseja copiar via NFS e, em seguida, usar o rsync localmente da montagem NFS para o local de destino.

Em um teste de um disco de rede WD MyBook Live, um ou mais rsyncs do NAS em uma rede Gigabit em direção a 2 discos USB locais não copiam mais de 10 MB / s (CPU: 80% usr, 20% sys), depois de exportar NFS e rsyncing localmente do compartilhamento NFS para ambos os discos, obtive um total de 45 MB / s (máximo de ambos os discos USB2) e pouco uso da CPU. A utilização do disco ao usar o rsync / SSH foi de cerca de 6% e o uso do rsync / NFS foi mais próximo de 24%, enquanto os dois discos USB2 foram próximos de 100%.

Então, movemos efetivamente o gargalo da CPU do NAS para os dois discos USB2.

Os motivos podem incluir: compactação, criptografia, número e tamanho de arquivos que estão sendo copiados, recursos de E / S de disco dos sistemas de origem e destino, sobrecarga de TCP ... Todos esses fatores podem influenciar o tipo de transferência que você está realizando.

Poste o comando rsync que você está usando e forneça detalhes sobre as especificações dos dois computadores.

Edit: A criptografia é frequentemente um fator limitante nas velocidades rsync. Você pode executar com ssh e uma cifra de criptografia mais leve, comoarcfour

Algo como: rsync -e "ssh -c arcfour"

Ou você pode usar um rsync / ssh modificado que pode desativar a criptografia. Consulte hpn-ssh: http://psc.edu/networking/projects/hpn-ssh

Mas, novamente, seu laptop tem uma unidade lenta em comparação com sua estação de trabalho. As gravações podem estar bloqueadas e aguardando a entrada / saída de seu laptop. Quais são suas expectativas reais de desempenho?

Depois de mais alguns testes, finalmente encontrei a resposta. rsyncusa tunelamento sobre ssh por padrão. A criptografia torna lento. Então, eu precisava contornar essas coisas de criptografia.

Solução 1: configurando um servidor rsync

Para usá-lo através do rsyncprotocolo, você precisa configurar um servidor rsyncd. Havia um /etc/init.d/rsyncscript no meu laptop, então imaginei que o rsyncd estava em execução. Eu estava errado. /etc/init.d/rsync startexiste silenciosamente, quando o rsync não está ativado /etc/default/rsync. Então você também precisa configurá-lo /etc/rsyncd.conf, o que é uma dor.

Se você conseguir fazer tudo isso, precisará usar rsync file.foo user@machine::directory. Por favor, note que existem dois pontos .

Solução 2: rsh-server da velha escola

No entanto, a configuração era muito complicada para mim. Acabei de instalar e rsh-serverno meu laptop. A chamada do rsync na estação de trabalho -e rexecusa o rsh em vez do ssh. O que quase dobrou o desempenho para 44,6 MB / s , o que ainda é lento. Os saltos de velocidade entre 58 MB / s e 33 Mb / s , o que indica que pode haver alguns problemas de controlo de tampão ou de congestionamento. Mas isso está além do escopo desta questão.

Essas são perguntas e respostas muito antigas, mas falta algo importante: se você estiver copiando dados já compactados ou criptografados, desative a compactação.

Se seus dados não forem compactados nem criptografados, você ainda deseja compactá-los uma vez! Rsync compacta com -z, ssh compacta com -C (pode ser por padrão). Não testei o que é melhor, pois meus dados são compactados.

Enquanto estou nisso, você pode desativar o encaminhamento de X e a alocação de TTY, resultando em:

rsync -avh -e "ssh -x -T -c arcfour -o Compression=no" $src $dst

Por fim, verifique (por exemplo, usando iptraf) que você está realmente usando a interface de rede que pensa estar usando. Para minha grande surpresa, notei que, no meu OSX, o ssh de saída estava vinculado ao IP na interface de saída padrão, em vez do IP na interface em que os pacotes deveriam ser roteados. Minha conexão direta em GB direta entre dois laptops também conectados por WiFi não estava sendo usada. Após a investigação, foi devido ao uso de 169.254 / 16, que o Mac coloca em todas as interfaces, e o computador de destino respondeu às solicitações de ARP, mesmo que a solicitação chegasse em uma interface diferente.