Meu laptop e minha estação de trabalho estão conectados a um switch Gigabit. Ambos rodam Linux. Mas quando copio arquivos com rsync
, ele funciona mal.
Eu recebo cerca de 22 MB/s. Eu não deveria teoricamente obter cerca de 125 MB/s? Qual é o fator limitante aqui?
EDIT: Eu conduzi alguns experimentos.
Desempenho de gravação no laptop
O laptop possui um sistema de arquivos xfs com criptografia completa de disco. Ele usa aes-cbc-essiv:sha256
o modo de cifra com comprimento de chave de 256 bits. O desempenho de gravação de 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 copiei estão em um software RAID-5 em 5 HDDs. No topo do ataque é um lvm. O próprio volume é 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 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 da rede
Eu corri 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
Os motivos podem incluir: compactação, criptografia, número e tamanho dos arquivos copiados, recursos de E/S de disco dos sistemas de origem e destino, sobrecarga de TCP... Todos esses são fatores que podem influenciar o tipo de transferência que você está realizando.
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 de rsync. Você pode executar 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: 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 esperando que a E/S vá para o seu laptop. Quais são suas reais expectativas de desempenho?
Outra maneira de mitigar o alto uso da CPU, mas ainda manter a funcionalidade do rsync, é passar de rsync/SSH para rsync/NFS. Você pode exportar os caminhos dos quais deseja copiar via NFS e 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 para 2 discos USB locais não copiariam 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 (maximizando os dois discos USB2) e pouco uso da CPU. A utilização de disco ao usar rsync/SSH foi de cerca de 6% e o uso de rsync/NFS ficou mais próximo de 24%, enquanto ambos os discos USB2 chegaram perto de 100%.
Assim, efetivamente transferimos o gargalo da CPU do NAS para os dois discos USB2.
Depois de mais alguns testes, eu finalmente encontrei a resposta.
rsync
usa tunelamento sobre ssh por padrão. A criptografia torna isso lento. Então eu precisava contornar essas coisas de criptografia.Solução 1: Configurando um servidor rsync
Para usá-lo através do
rsync
protocolo, você precisa configurar um servidor rsyncd. Havia um/etc/init.d/rsync
script no meu laptop, então imaginei que o rsyncd estava em execução. Eu estava errado./etc/init.d/rsync start
existe silenciosamente, quando o rsync não está habilitado no/etc/default/rsync
. Então você também precisa configurá-lo no/etc/rsyncd.conf
, o que é uma dor.Se você fizer tudo isso, você tem que usar
rsync file.foo user@machine::directory
. Observe que há dois pontos .Solução 2: servidor rsh à moda antiga
No entanto, a configuração era muito complicada para mim. Então, acabei de instalar e
rsh-server
no meu laptop. Invocar rsync na estação de trabalho com-e rexec
então usa rsh em vez de ssh. O que quase dobrou o desempenho para 44,6 MB/s , o que ainda é lento. A velocidade oscila entre 58 MB/s e 33 MB/s , o que indica que pode haver algum problema de buffer ou controle de congestionamento. Mas isso está além do escopo desta questão.Essas são perguntas e respostas muito antigas, mas falta uma coisa importante: se você estiver copiando dados já compactados ou criptografados, desative a compactação.
Se seus dados não estiverem compactados nem criptografados, você ainda deseja compactar apenas uma vez! Rsync compacta com -z, ssh compacta com -C (pode ser por padrão). Eu não testei o que é melhor, pois meus dados são compactados.
Enquanto estou nisso, você pode desativar o encaminhamento X e a alocação de TTY, resultando em:
Por fim, certifique-se (por exemplo, usando
iptraf
) de que você está realmente usando a interface de rede que pensa estar usando. Para minha grande surpresa, observei 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 de GB entre dois laptops também conectados por WiFi não estava sendo usada. Após 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, mesmo que a solicitação tenha chegado em uma interface diferente.