Por que o scp é tão lento e como torná-lo mais rápido?

Question

Estou tentando copiar um lote de arquivos com scp , mas é muito lento. Este é um exemplo com 10 arquivos:

$ time scp cap_* user@host:~/dir
cap_20151023T113018_704979707.png    100%  413KB 413.2KB/s   00:00    
cap_20151023T113019_999990226.png    100%  413KB 412.6KB/s   00:00    
cap_20151023T113020_649251955.png    100%  417KB 416.8KB/s   00:00    
cap_20151023T113021_284028464.png    100%  417KB 416.8KB/s   00:00    
cap_20151023T113021_927950468.png    100%  413KB 413.0KB/s   00:00    
cap_20151023T113022_567641507.png    100%  413KB 413.1KB/s   00:00    
cap_20151023T113023_203534753.png    100%  414KB 413.5KB/s   00:00    
cap_20151023T113023_855350640.png    100%  412KB 411.7KB/s   00:00    
cap_20151023T113024_496387641.png    100%  412KB 412.3KB/s   00:00    
cap_20151023T113025_138012848.png    100%  414KB 413.8KB/s   00:00    
cap_20151023T113025_778042791.png    100%  413KB 413.4KB/s   00:00    

real    0m43.932s
user    0m0.074s
sys 0m0.030s

O mais estranho é que a taxa de transferência é de cerca de 413KB / seo tamanho do arquivo é de cerca de 413KB, então realmente deve transferir um arquivo por segundo, mas está demorando cerca de 4,3 segundos por arquivo.

Alguma idéia de onde esta sobrecarga vem, e existe alguma maneira de torná-la mais rápida?

    

Answer 1

@ O comentário de wurtel provavelmente está correto: há muita sobrecarga estabelecendo cada conexão. Se você puder consertar isso , você ficará mais rápido transferências (e se você não pode, basta usar @ rsync workaound do roaima). Eu fiz uma experiência de transferência de arquivos de tamanho semelhante ( head -c 417K /dev/urandom > foo.1 e fiz algumas cópias desse arquivo) para um host que leva um tempo para se conectar (HOST4) e um que responde muito rapidamente (HOST1):

$ time ssh $HOST1 echo


real    0m0.146s
user    0m0.016s
sys     0m0.008s
$ time scp * $HOST1:
foo.1                                         100%  417KB 417.0KB/s   00:00    
foo.2                                         100%  417KB 417.0KB/s   00:00    
foo.3                                         100%  417KB 417.0KB/s   00:00    
foo.4                                         100%  417KB 417.0KB/s   00:00    
foo.5                                         100%  417KB 417.0KB/s   00:00    

real    0m0.337s
user    0m0.032s
sys     0m0.016s
$ time ssh $HOST4 echo


real    0m1.369s
user    0m0.020s
sys     0m0.016s
$ time scp * $HOST4:
foo.1                                         100%  417KB 417.0KB/s   00:00    
foo.2                                         100%  417KB 417.0KB/s   00:00    
foo.3                                         100%  417KB 417.0KB/s   00:00    
foo.4                                         100%  417KB 417.0KB/s   00:00    
foo.5                                         100%  417KB 417.0KB/s   00:00    

real    0m6.489s
user    0m0.052s
sys     0m0.020s
$ 

    

Answer 2

Você pode usar rsync (acima de ssh ), que usa uma única conexão para transferir todos os arquivos de origem.

rsync -avP cap_* user@host:dir

Se você não tem rsync (e porque não !?), você pode usar tar com ssh desta forma, o que evita a criação de um arquivo temporário:

tar czf - cap_* | ssh user@host tar xvzfC - dir

O rsync deve ser preferido, sendo todas as outras coisas iguais, porque é reinicializável no caso de uma interrupção.

    

Answer 3

É a negociação da transferência que leva tempo. Em geral, operações em arquivos n de b bytes demoram muito, muito mais do que uma única operação em um único arquivo de n * b bytes. Isto também é verdade, e. para E / S de disco.

Se você observar com cuidado, verá que a taxa de transferência, neste caso, é tamanho_do_arquivo / s.

Para transferir arquivos com mais eficiência, agrupe-os com tar e, em seguida, transfira o tarball:

tar cvf myarchive.tar cap_20151023T*.png

ou, se você também quiser compactar o arquivo,

tar cvzf myarchive.tar.gz myfile*

Se comprimir ou não depende do conteúdo do arquivo, por exemplo. se forem JPEGs ou PNGs, a compactação não terá efeito algum.

    

Answer 4

Outra razão pela qual o scp é mais lento do que deveria ser, especialmente em redes de alta largura de banda, é que ele tem buffers de controle de fluxo interno definidos estaticamente que acabam se tornando gargalos de desempenho de rede.

HPN-SSH é uma versão corrigida do OpenSSH que aumenta o tamanho desses buffers. Faz uma diferença massiva para a velocidade de transferência scp (veja os gráficos no site, mas também falo por experiência pessoal). Claro, para obter os benefícios que você precisa para instalar o HPN-SSH em todos os seus hosts, mas vale a pena se você precisar transferir arquivos grandes regularmente.

    

Answer 5

Eu usei a técnica descrita aqui que usa gzip e netcat paralelos para rapidamente compactar e copiar dados.

Tudo se resume a:

# SOURCE: 
> tar -cf - /u02/databases/mydb/data_file-1.dbf | pigz | nc -l 8888

# TARGET:
> nc <source host> 8888 | pigz -d | tar xf - -C /

Isso usa tar para reunir o arquivo ou arquivos. Em seguida, usa pigz para obter muitos threads cpu para compactar e enviar o arquivo, a transmissão da rede está usando netcat. No lado do recebimento, o netcat ouve, então, descompacta (em paralelo) e untars.

    

Answer 6

Acabou de ter esse problema fazendo uma transferência site a site de um arquivo mp4 grande via scp . Estava ficando ~ 250KB / s. Depois de desativar a proteção contra inundação do UDP (FP) no firewall de destino, a taxa de transferência aumentou para 6,5 MB / s. Ao voltar a ligar o FP, a taxa caiu para ~ 250KB / s.

Remetente: cygwin, Receptor: Fedora 20, Firewall Sophos UTM.

O que o SSH usa o UDP? @ superuser.com - Não diretamente do que eu li.

Ao analisar o registro do firewall, a detecção de inundação estava ocorrendo na origem & dest portas 4500 sobre os endereços IP públicos, não os endereços VPN internos site-to-site privados. Assim, parece que o meu problema é provavelmente uma situação de Traversal de NAT em que os dados de scp TCP são finalmente encriptados e encapsulados em ESP & Pacotes UDP e, consequentemente, sujeitos a FP. Para remover scp da equação, executei uma operação de cópia de arquivos do Windows na VPN e notei um desempenho semelhante ao scp com e sem o FP ativado. Também executei um teste iperf sobre TCP e notei 2Mbits / seg com FP e 55Mbits / seg sem.

Como o NAT-T funciona com o IPSec? @ cisco.com