Por que meu rsync é tão lento?

40

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

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

EDITAR: realizei algumas experiências.

Escrever desempenho no laptop

O laptop tem um sistema de arquivos xfs com criptografia total de disco. Usa o modo de cifra aes-cbc-essiv:sha256 com um comprimento de chave de 256 bits. O desempenho de gravação em disco é 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

Desempenho de leitura na estação de trabalho

Os arquivos que copiei estão em um software RAID-5 em 5 HDDs. No topo do ataque está um lvm. O volume em si é criptografado com a mesma cifra. A estação de trabalho tem uma CPU FX-8150 que possui um conjunto de instruções AES-NI nativo que acelera a criptografia. O desempenho de 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

Eu corri iperf entre os dois clientes. O desempenho da rede é 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
    
por iblue 07.04.2012 / 23:04

4 respostas

18

Outra forma de mitigar o alto uso da CPU, mas ainda manter a funcionalidade do rsync, é mudar de rsync / SSH para rsync / NFS. Você pode exportar os caminhos que deseja copiar através do NFS e, em seguida, usar o rsync localmente da montagem do 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 para 2 discos USB locais não copiariam mais de 10MB / seg (CPU: 80% usr, 20% sys), depois de exportar via NFS e rsyncing localmente do compartilhamento NFS para os dois discos, obtive um total de 45MB / s (maximizando os dois discos USB2) e pouca utilização da CPU. A utilização de disco ao usar rsync / SSH foi de cerca de 6% e o uso de rsync / NFS foi mais próximo de 24%, enquanto os dois discos USB2 ficaram próximos a 100%.

Portanto, movemos o gargalo da CPU do NAS para os dois discos USB2.

    
por 02.08.2012 / 22:50
26

Os motivos podem incluir: compactação, criptografia, o número e o tamanho dos arquivos copiados, os recursos de E / S de disco dos sistemas de origem e destino, sobrecarga TCP ... Esses são todos os fatores que podem influenciar o tipo de transferência re-conduzindo.

Por favor, poste o comando rsync que você está usando e forneça detalhes sobre as especificações de ambos os computadores.

Editar: A criptografia geralmente é um fator limitante nas velocidades do rsync. Você pode rodar com ssh e uma cifra de criptografia mais leve como arcfour

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

Ou você pode usar um rsync / ssh modificado que pode desabilitar a criptografia. Veja hpn-ssh: link

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

    
por 07.04.2012 / 23:12
9

Depois de mais alguns testes, finalmente encontrei a resposta. rsync usa tunelamento sobre ssh por padrão. A criptografia torna isso lento. Então eu precisava contornar esse material de criptografia.

Solução 1: Configurando um servidor rsync

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

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

Solução 2: servidor rsh antigo

No entanto, a configuração era muito complicada para mim. Então eu instalei e rsh-server no meu laptop. Chamar rsync na estação de trabalho com -e rexec , em seguida, usa rsh em vez de ssh. O que quase dobrou o desempenho para 44.6 MB / s , o que ainda é lento. A velocidade é refletida entre 58 MB / s e 33 MB / s , o que indica que pode haver alguns problemas de buffer ou controle de congestionamento. Mas isso está além do escopo desta questão.

    
por 08.04.2012 / 13:25
2

Estas são perguntas e respostas muito antigas, mas uma coisa importante está faltando: se você estiver copiando dados já compactados ou criptografados, desative a compactação.

Se os seus dados não estiverem compactados nem criptografados, você ainda deseja compactá-los apenas uma vez! O rsync compacta com -z, ssh compacta com -C (pode ser por padrão). Eu não testei o que é melhor, pois meus dados estã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 último, certifique-se (por exemplo, usando iptraf ) que você está realmente usando a interface de rede que você acha que está usando. Eu tenho a minha grande surpresa, notei que no meu OSX o ssh de saída estava ligado ao IP na interface de saída padrão ao invés do IP na interface onde os pacotes deveriam ser roteados. Minha conexão cruzada 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 respondendo a solicitações ARP, embora a solicitação tenha chegado em uma interface diferente.

    
por 22.07.2017 / 21:28