Por que o rsync é mais rápido que o NFS?

Poucos dias atrás, notei algo bastante estranho (pelo menos para mim). Corri o rsync copiando os mesmos dados e os excluindo posteriormente para a montagem do NFS, chamada /nfs_mount/TEST. Este /nfs_mount/TESTé hospedado / exportado de nfs_server-eth1. O MTU em ambas as interfaces de rede é 9000, o comutador entre também suporta quadros jumbo. Se eu rsync -av dir /nfs_mount/TEST/obtiver velocidade de transferência de rede X MBps. Se eu rsync -av dir nfs_server-eth1:/nfs_mount/TEST/conseguir velocidade de transferência de rede, pelo menos, 2X MBps. Minhas opções de montagem do NFS são nfs rw,nodev,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountvers=3,mountproto=tcp.

Conclusão: ambas as transferências passam pela mesma sub-rede da rede, mesmos fios, mesmas interfaces, lêem os mesmos dados, gravam no mesmo diretório etc. A única diferença é através do NFSv3 e a outra no rsync.

O cliente é o Ubuntu 10.04, o servidor Ubuntu 9.10.

Como é que o rsync é muito mais rápido? Como fazer o NFS corresponder a essa velocidade?

obrigado

Editar: observe que eu uso o rsync para gravar no compartilhamento NFS ou no SSH no servidor NFS e gravar localmente lá. Nas duas vezes rsync -av, iniciando com o diretório de destino claro. Amanhã vou tentar com cópia simples.

Edit2 (informações adicionais): o tamanho do arquivo varia de 1 KB a 15 MB. Os arquivos já estão compactados, tentei comprimir ainda mais, sem sucesso. Eu criei um tar.gzarquivo disso dir. Aqui está o padrão:

• rsync -av dir /nfs_mount/TEST/ = transferência mais lenta;
• rsync -av dir nfs_server-eth1:/nfs_mount/TEST/= rsync mais rápido com jumbo-frames habilitado; sem jumbo-frames é um pouco mais lento, mas ainda significativamente mais rápido que o diretamente para o NFS;
• rsync -av dir.tar.gz nfs_server-eth1:/nfs_mount/TEST/ = aproximadamente o mesmo que seu equivalente não-tar.gz;

Testes com cpe scp:

• cp -r dir /nfs_mount/TEST/= ligeiramente mais rápido que, rsync -av dir /nfs_mount/TEST/mas ainda significativamente mais lento que rsync -av dir nfs_server-eth1:/nfs_mount/TEST/.
• scp -r dir /nfs_mount/TEST/= mais rápido no geral, supera levemente rsync -av dir nfs_server-eth1:/nfs_mount/TEST/;
• scp -r dir.tar.gz /nfs_mount/TEST/ = aproximadamente o mesmo que seu equivalente não-tar.gz;

Conclusão, com base nestes resultados: Para este teste, não há diferença significativa se estiver usando arquivo grande tar.gz ou muitos pequenos. Os quadros Jumbo ligados ou desligados também quase não fazem diferença. cpe scpsão mais rápidos que seus respectivos rsync -avequivalentes. Gravar diretamente no compartilhamento NFS exportado é significativamente mais lento (pelo menos 2 vezes) do que gravar no mesmo diretório pelo SSH, independentemente do método usado.

As diferenças entre cpe rsyncnão são relevantes neste caso. Eu decidi tentar cpe scpapenas para ver se eles mostram o mesmo padrão e mostram - 2X diferença.

Enquanto uso rsyncou cpnos dois casos, não consigo entender o que impede o NFS de atingir a velocidade de transferência dos mesmos comandos pelo SSH.

Por que a gravação no compartilhamento NFS é 2X mais lenta que a gravação no mesmo local através do SSH?

Edit3 (NFS servidor / etc / exportações opções): rw,no_root_squash,no_subtree_check,sync. Do cliente / proc / mounts mostra: nfs rw,nodev,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountvers=3,mountproto=tcp.

Obrigado a todos!

Talvez não seja uma velocidade de transferência mais lenta, mas maior latência de gravação. Tente montar o compartilhamento NFS assíncrono em vez de sincronizar e veja se isso diminui a diferença de velocidade. Quando você faz o rsync sobre ssh, o processo rsync remoto grava de forma assíncrona (rapidamente). Mas, ao gravar no compartilhamento nfs montado de forma síncrona, as gravações não são confirmadas imediatamente: o servidor NFS aguarda até atingir o disco (ou mais provavelmente o cache do controlador) antes de enviar a confirmação ao cliente NFS de que a gravação foi bem-sucedida.

Se 'async' resolver seu problema, saiba que, se algo acontecer com o servidor NFS no meio da gravação, você poderá muito bem acabar com dados inconsistentes no disco. Contanto que essa montagem NFS não seja o armazenamento principal desses dados (ou de qualquer outro), você provavelmente ficará bem. É claro que você estaria no mesmo barco se você desconectasse o servidor nfs durante / após a execução do rsync-over-ssh (por exemplo, o rsync retorna tendo 'terminado', o servidor nfs trava, os dados não confirmados no cache de gravação estão perdidos. deixando dados inconsistentes no disco).

Embora não seja um problema em seu teste (sincronizando novos dados), lembre-se de que o rsync over ssh pode gerar demandas significativas de CPU e IO no servidor remoto antes que um único byte seja transferido enquanto calcula somas de verificação e gera a lista de arquivos que precisam ser Atualizada.

O NFS é um protocolo de compartilhamento, enquanto o Rsync é otimizado para transferências de arquivos; existem muitas otimizações que podem ser feitas quando você sabe a priori que seu objetivo é copiar arquivos o mais rápido possível, em vez de fornecer acesso compartilhado a eles.

Isso deve ajudar: http://en.wikipedia.org/wiki/Rsync

Rsync é um protocolo de arquivo que transfere apenas os bits alterados entre os arquivos. O NFS é um protocolo de arquivo de diretório remoto que lida com tudo o tempo todo ... de certa forma, como um SMB. Os dois são diferentes e para diferentes propósitos. Você pode usar o Rsync para transferir entre dois compartilhamentos NFS.

Isto é interessante. Uma possibilidade que você talvez não tenha considerado é o conteúdo / tipo de arquivo que está transmitindo.

Se você tem vários arquivos pequenos (por exemplo, emails em arquivos individuais), a eficiência do NFS pode estar diminuindo devido ao não uso da MTU completa (talvez isso seja menos provável com o TCP sobre o UDP).

Como alternativa, se você tiver arquivos / dados altamente compactáveis, CPUs rápidas e uma rede que não tenha a velocidade da CPU (*), poderá obter a aceleração apenas da compressão implícita no link ssh.

Uma terceira possibilidade é que os arquivos (ou uma versão dos mesmos) já existam no destino. Nesse caso, a aceleração seria porque o protocolo rsync poupa a transferência dos arquivos.

(*) Nesse caso, por 'velocidade', estou me referindo à taxa na qual a CPU pode compactar dados em comparação com a taxa que a rede pode transmitir dados; por exemplo, leva 5 segundos para enviar 5 MB através do fio, mas a CPU pode compactar esses 5 MB em 1 MB em 1 segundo. Nesse caso, o tempo de transmissão dos dados compactados seria ligeiramente superior a 1 segundo, enquanto os dados não compactados são de 5 segundos.

Eu também uso -e "ssh Ciphers = arcfour" para aumentar a taxa de transferência.

se seu objetivo é copiar todos os arquivos de um lugar para outro, o tar / netcat será a opção mais rápida. se você sabe que possui muito espaço em branco em seus arquivos (zeros), use a opção -i.

FONTE: tar cvif - / caminho / para / fonte | nc DESTINO PORTNUM DESTINATION: cd / caminho / para / fonte && nc -l PORTNUM | tar xvif -

se você sabe que seus dados são compactáveis, use a compactação em seus comandos tar -z -j -Ipixz

Sou fã de pixz .. paralelo xz, oferece ótima compactação e posso ajustar o número de CPUs que tenho na largura de banda da rede. se eu tiver uma largura de banda mais lenta, usarei uma compactação mais alta, por isso estou esperando na CPU mais do que na rede .. se eu tiver uma rede rápida, usarei uma compactação muito baixa:

FONTE: tar cvif - / caminho / para / fonte | pixz -2 -p12 | nc DESTINATION PORTNUM # tar, ignora zeros, compactação pixz de nível 2 usando 12 núcleos de CPU DESTINO: nc -l PORTNUM | tar -Ipixz -xvif

se você ajustar o nível de compressão e os núcleos corretamente, dependendo do seu conjunto de dados, poderá manter a rede quase saturada e fazer compressão suficiente, pois o gargalo se tornará o disco (geralmente o lado de gravação, se os sistemas de disco de leitura e gravação estiverem disponíveis). o mesmo).

quanto ao rsync, acredito que ele pula zeros da mesma forma que o tar faz com essa opção, por isso está transmitindo menos dados que o NFS. O NFS não pode fazer suposições sobre os dados, por isso precisa transmitir todos os bytes, juntamente com a sobrecarga do protocolo NFS. rsync tem alguma sobrecarga ..

O netcat não possui basicamente nenhum .. ele enviará pacotes TCP completos que não contêm nada além de dados importantes para você.

com o netcat, como no scp, você precisa enviar todos os dados de origem o tempo todo, não pode ser seletivo como no rsync, para que não seja adequado para backups incrementais ou esse tipo de coisa, mas é bom para copiar dados ou arquivar.

Você tem a configuração de bloqueio de arquivos no nfsshare? Você pode obter muito mais desempenho se isso estiver desativado.

Suponho que o aumento da velocidade se deva ao menos em parte ao fato de "rsync src host: / path" gerar um processo local na máquina remota para enviar / receber, cortando efetivamente sua E / S pela metade.