Entendendo por que tal discrepância na transferência de rede?

Question

Resumo:

Não consigo entender uma discrepância peculiar na transferência de rede.

• Por que existe essa discrepância na sincronização de uma máquina para outra e vice-versa?

Além disso:

• Dada a velocidade máxima de transferência da rede é de cerca de 110 M / seg, e a velocidade do disco local para uma operação semelhante é de cerca de 200 M / seg (por isso, não há gargalo), por que há uma velocidade muito menor entre os dois máquinas, do que os teóricos 100M / seg?

Detalhes:

Primeiro de tudo, o servidor é

# uname -a                                                                                                                                                              
FreeBSD das 10.1-RELEASE-p8 FreeBSD 10.1-RELEASE-p8 #25 d0fb866(releng/10.1): Thu Nov     13 07:57:26 EST 2014     root@bellicose:/usr/obj/root/pcbsd-build-10-STABLE/git/freebsd/    sys/GENERIC  amd64

O cliente é:

# uname -a
Darwin compute.internal 13.4.0 Darwin Kernel Version 13.4.0: Sun Aug 17 19:50:11 PDT 2014; root:xnu-2422.115.4~1/RELEASE_X86_64 x86_64

Ambas as máquinas têm 16GB de RAM.

Ao fazer um rsync local no servidor, um tipo de sabe o que esperar como velocidade de disco, pelo menos nessa circunstância.

Usando um arquivo binário, test.bin, 732M, o rsync local no servidor FreeBSD mostra cerca de 200 M / s:

# rsync --stats -h test.bin copy.bin

[....]

sent 732.54M bytes  received 35 bytes  209.30M bytes/sec
total size is 732.36M  speedup is 1.00

Isso é cerca de 200 M / s.

No cliente do mac mini eu tenho quase 70M / seg:

# rsync --progress --stats -h   test.bin copy.bin
test.bin
        732.36M 100%   70.06MB/s    0:00:09 (xfr#1, to-chk=0/1)

[....]

sent 732.54M bytes  received 35 bytes  69.77M bytes/sec
total size is 732.36M  speedup is 1.00

Agora, faça um teste de velocidade de rede com iperf :

No servidor (o servidor do FreeBSD):

# iperf -f M -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 0.06 MByte (default)
------------------------------------------------------------
[  4] local 192.168.1.5 port 5001 connected with 192.168.1.226 port 50757
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-30.0 sec  3356 MBytes   112 MBytes/sec

No cliente (OS X mac mini):

# iperf -f M -M 9000 -c 192.168.1.5 -t 30 -w 80K
WARNING: attempt to set TCP maxmimum segment size to 9000 failed.
Setting the MSS may not be implemented on this OS.
------------------------------------------------------------
Client connecting to 192.168.1.5, TCP port 5001
TCP window size: 0.08 MByte (WARNING: requested 0.08 MByte)
------------------------------------------------------------
[  4] local 192.168.1.226 port 50757 connected with 192.168.1.5 port 5001
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-30.0 sec  3356 MBytes   112 MBytes/sec

Então, eu poderia supor que a conexão de rede (um cabo cat 7 direto entre as duas nics) é de cerca de 110 M / seg.

Agora, esta é a situação intrigante:

Se eu rsync do servidor FreeBSD para o mac mini, eu obtenho uma velocidade de transferência de cerca de 50 M / seg:

# rsync --progress --stats -h test.bin -e "ssh -l gsl" '192.168.1.226:/tmp/'
Password:
test.bin
        732.36M 100%   57.10MB/s    0:00:12 (xfr#1, to-chk=0/1)

[....]

sent 732.45M bytes  received 46 bytes  50.51M bytes/sec
total size is 732.36M  speedup is 1.00

Mas o rsync na direção oposta dá uma taxa de transferência muito menor, 20M / s:

# rsync --progress --stats -h   test.bin -e "ssh -l gsl" '192.168.1.6:/tmp/'
test.bin
        732.36M 100%   19.55MB/s    0:00:35 (xfr#1, to-chk=0/1)

[....]

sent 732.54M bytes  received 35 bytes  20.07M bytes/sec
total size is 732.36M  speedup is 1.00

Minhas duas perguntas:

• Por que existe essa discrepância na sincronização de uma máquina para outra e vice-versa?

Além disso:

• Dada a velocidade máxima de transferência da rede é de cerca de 110 M / seg, e a velocidade do disco local para uma operação semelhante é de cerca de 200 M / seg (por isso, não há gargalo), por que há uma velocidade muito menor entre os dois máquinas, do que os teóricos 100M / seg?

Alguém poderia ajudar a entender isso, talvez oferecendo alguns conselhos sobre como melhorar a velocidade de transferência?

Atualização: Com base na resposta do @dhag, tentei copiar um arquivo com netcat , ou seja, sem compactação:

No lado "servidor" (push):

time cat test.bin | nc -l 2020
nc -l 2020  0.25s user 6.29s system 77% cpu 8.462 total

No lado de recebimento (FreeBSD):

time nc 192.168.1.226 2020 > test.bin
nc 192.168.1.226 2020 > test.bin  0.09s user 4.00s system 62% cpu 6.560 total

Se não me engano, isso deve significar 732M / 6,29s = 117M / seg, o que excede as estatísticas de iperf . Talvez um problema de cache?

Atualização 2: Usando rsync sem criptografia (somente possível se estiver usando um daemon e o protocolo rsync: //):

# rsync  --progress --stats -h  test.bin rsync://[email protected]/share        ⏎
test.bin
     732.36M 100%  112.23MB/s    0:00:06 (xfer#1, to-check=0/1)

[....]

sent 732.45M bytes  received 38 bytes  112.69M bytes/sec
total size is 732.36M  speedup is 1.00

Isso também confirma as idéias de @dhag.

    

Answer 1

Eu só posso fornecer um palpite, que é que a discrepância é explicada por variáveis computacionais, memória, cache ou características de disco dos dois hosts:

• Se assumirmos que a CPU é um gargalo, então faria algum sentido se a máquina mais lenta fosse mais lenta no envio (isso pressupõe que a criptografia é mais computacionalmente pesada que a descriptografia). Isso pode ser testado alternando para uma cifra mais leve para ser computada (tente adicionar -c arcfour à sua linha de comando SSH; nesse caso, passando --rsh="ssh -c arcfour" para rsync ).

• Se assumirmos que os arquivos estão sendo lidos / gravados diretamente de / para o disco, o disco poderia ser um gargalo; velocidades de leitura de 100 MBps estão bem ao alcance de computadores mais modernos, mas não de computadores mais antigos, ou computadores rodando em drives de classe de laptop (como, eu acredito, o Mac Mini).

• Se ainda assumirmos que o sistema operacional usa caches de sistema de arquivos, a situação pode ser ainda mais complicada:

  • Se o arquivo de origem estiver contido no cache do sistema de arquivos, na RAM, ele poderá ser lido muito mais rapidamente do que 100 MBps;

  • se o sistema de destino aplicar o cache de gravação e for capaz de encaixar uma parte significativa do arquivo na RAM (no seu caso, deve ser, já que a RAM é muito maior que o arquivo de teste), a gravação está completa antes de chegar ao disco (isso pode significar que seus 200MBps medidos são).

O disco versus cache desconhecido pode ser testado ao liberar o cache do sistema de arquivos antes da leitura (como fazer isso depende do sistema operacional): o envio do arquivo será pelo menos tão lento quanto o disco determinar. Por outro lado, lendo o arquivo completamente antes de enviá-lo (talvez com cat file.bin >/dev/null ), pode-se influenciar o sistema operacional para armazená-lo em cache.

Para investigar se a CPU é um problema, faria sentido executar top enquanto a transferência estiver em andamento; Se o processo rsync ou ssh estiver recebendo 100% de um núcleo, isso seria um gargalo.