Como encontrar o gargalo durante a transferência de arquivos enormes entre dois hosts

Question

Frequentemente precisamos transferir arquivos enormes (acima de 50 GB) entre dois hosts, e a taxa de transferência nunca parece atingir a taxa de transferência esperada para a rede. Existem vários pontos que podem ser o gargalo, mas cada um dos seus limites superiores teóricos é caminho acima da taxa de transferência real. Aqui está uma configuração típica:

Laptop - > 802.11n - > AP - > Cabo CAT 6 - > Roteador 10/100 Mbits - > Desktop

Nesta conexão, o gargalo é claramente o roteador, o que limitaria a taxa de transferência a 100 Mbits / seg. Mesmo assim, raramente vejo uma taxa de transferência (com scp) superior a 9,5 MB / s, o que representa 76 Mbits / s, ou apenas 76% do limite máximo teórico.

Pode haver realmente uma sobrecarga de 24% no ponto de acesso, ou há algo mais que limita a velocidade? Pode ser E / S de disco (embora o SATA esteja classificado em 1,5 Gbps) ou qualquer coisa na placa-mãe entre o disco e a NIC (como posso medir isso?).

Existe uma maneira de saber com certeza (*) onde está o gargalo? Se eu não conseguir mais de 76 Mbps de um roteador de 100 Mbps, a atualização da rede para gigabit aumentará o throughput ou ainda receberei 76 Mbps porque o gargalo está em outro lugar?

(*) ou pelo menos de certa forma convincente o suficiente para que um chefe concordasse em investir para atualizar aquela parte da rede

    

Answer 1

seu problema é que você está testando muitas coisas ao mesmo tempo:

• velocidade de leitura do disco
• criptografia SSH
• sem fio
• Descriptografia de SSH
• velocidade de gravação em disco

Desde que você mencionou o SSH, vou assumir que este é um sistema unix ...

Você pode descartar qualquer problema com a velocidade de leitura de disco com um simples

dd if=yourfile of=/dev/null #or
pv yourfile > /dev/null

no final do recebimento, você pode fazer um simples teste de gravação em disco

dd if=/dev/zero of=testfile bs=1M count=2000 # or
dd if=/dev/zero bs=1M count=2000 | pv > testfile

dd não é realmente um "benchmark", mas como scp usa IO sequencial, ele é próximo o suficiente

você também pode testar o SSH fazendo algo como

dd if=/dev/zero bs=1M count=100 | ssh server dd of=/dev/null # or
dd if=/dev/zero bs=1M count=100 | pv | ssh server dd of=/dev/null

finalmente, para descartar o SSH como o gargalo, você pode usar o nc para testar o desempenho da rede

server$ nc -l 1234 > /dev/null
client$ dd if=/dev/zero bs=1M count=100 | pv | nc server 1234 # or
client$ dd if=/dev/zero bs=1M count=100 | nc server 1234

se você realmente quiser testar corretamente a rede, instale e use algo como iperf, mas o nc é um bom começo.

Eu começaria com o teste nc, pois isso excluiria a maioria das coisas. Você também deve executar os testes sem usar o wireless. O 802.11n pode facilmente maximizar uma porta de 100mbit, mas somente se você configurá-lo corretamente.

(O padrão do Ubuntu > = 12.04 para netcat-openbsd. nc -l -p 1234 > /dev/null pode ser o que você deseja se estiver usando o tradicional netcat).

    

Answer 2

Pense desta maneira;

Você tem um lento (discos portáteis são lentos) de disco SATA executando um sistema de arquivos ou de outra, que então se transforma em um protocolo de compartilhamento de arquivos baseada em IP tais como SMB. Isso, então, se transformou em formato wifi que, em seguida, atinge um AP, que, em seguida, passa por cima de Ethernet com fio (que exige algum reformating) a um switch.router muito lento, em seguida, em um-muito-lento-desktop, provavelmente, fica quebrado de volta seu arquivo formato do sistema de escolha e, finalmente, para o disco. Tudo isso acontece em todos os pacotes, a maioria, se não todos os quais requerem um pacote de reconhecer enviado de volta antes de enviar o próximo pacote.

Estou surpreso que você esteja vendo tanta velocidade em você!

Aqui está uma pista, ligue o computador portátil à 100Mbps switch / roteador quando você precisa transferir os arquivos - a sério, vai ser muito, muito mais rápido. Além disso, considere discos mais rápidos em cada extremidade e verifique se você está usando um mecanismo eficiente de transferência de arquivos também.

Espero que isso ajude.

    

Answer 3

Como alude o Chopper3, também tente usar o rsync-over-ssh para arquivos desse tamanho, pois há uma boa chance de que algo possa dar errado; nada é mais difícil do que obter 45GB através de uma transferência de 50GB e falhar. É possível que também diminua a sua sobrecarga, mas eu pessoalmente não testei isso com arquivos grandes demais.

Ao transferir milhares de arquivos pequenos, o rsync também pode diminuir substancialmente a sobrecarga - um arquivo de 75K / 1500 dir / teste de tamanho médio de 5.6K que rodei levou 12min com FTP e SFTP, 10min com SCP, mas apenas 1min50sec com rsync- over-ssh devido à diminuição da sobrecarga de configuração / desmontagem. O Rsync sem SSH foi apenas 20sec mais rápido a 1min33seg.

    

Answer 4

Você pode usar este comando para medir a velocidade de leitura de seus discos:

hdparm -tT /dev/sdX

(substitua X pela letra da unidade)

1.5 / 3 / 6gbps é tecnicamente a velocidade de transferência de sata, mas a maioria dos discos é capaz de ler continuamente de 50-60mbps.