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

59

Estou tentando copiar um lote de arquivos, scpmas é 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 estranho é que a taxa de transferência é de cerca de 413KB / s e o tamanho do arquivo é de cerca de 413KB; portanto, ele deve transferir um arquivo por segundo, no entanto, leva cerca de 4,3 segundos por arquivo.

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

scp time batch-jobs

— Laurent
fonte

3

Que velocidade você espera (ou seja, existe outro protocolo que mostre velocidades de transferência mais altas entre as mesmas duas máquinas)? O que acontece quando você scp um arquivo muito maior (talvez a concatenação de todos os seus arquivos de 413 KB)?

— dhag

6

Parece que o sistema remoto pode estar tentando resolver o endereço IP do cliente para um nome e você precisa aguardar um tempo limite antes que a sessão prossiga. Você pode investigar a correção disso (por exemplo, adicione seu endereço IP ao arquivo / etc / hosts do destino).

— wurtel

4

Vale ressaltar que o sinalizador -C permite a compactação durante a transferência. Embora seu problema pareça estar sobrecarregando as transferências, a compactação é basicamente "gratuita" e quase sempre ajuda.

— Sam

@ Wurtel: Eu não vejo o que você está vendo, tudo que vejo são momentos. Só deve ser necessária uma única chamada DNS reversa.

— James Reinstate Monica Polk

Você confia no SCP para segurança ou apenas para cópia remota?

— Freiheit

17

O comentário de @ wurtel provavelmente está correto: há muitas despesas gerais estabelecendo cada conexão. Se você pode consertar que obterá transferências mais rápidas (e se não conseguir, basta usar a rsyncsolução alternativa do @ roaima ). Fiz um experimento transferindo arquivos de tamanho semelhante ( head -c 417K /dev/urandom > foo.1e fiz algumas cópias desse arquivo) para um host que demora um pouco para 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
$

11

Obrigado, isso é muito interessante. A saída do scp é meio que quebrada se mostrar ao mesmo tempo, mesmo que seja completamente diferente de um host para outro. Provavelmente, eles devem incluir o tempo de conexão no tempo total.

— 18717

11

Então, sua hipótese é estabelecer uma nova conexão uma vez para cada arquivo?

— Rogerdpack 27/09/19

59

Você pode usar rsync(sobre 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 por que não !?) que você pode usar tarcom sshcomo esta, o que evita a criação de um arquivo temporário:

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

A rsyncdeve ser preferida, todas as outras coisas sendo iguais, porque é restartable em caso de uma interrupção.

— roaima
fonte

6

Você está dizendo que uma única scpinvocação não usaria uma única conexão para transferir todos os arquivos?

— um CVn

11

No caso do tarpipe, não há necessidade de ambos f -os lados, pois o tar gera / lê de stdout / stdin por padrão. Então tar cz cap_* | ssh user@host tar xvzC dirfaria isso.

— tremby 24/10/2015

11

@ tremby não necessariamente. tarpode ser compilado com diferentes valores padrão (veja tar --show-defaultsse você está usando o GNU tar, ou /etc/default/tarde outra forma, e em ambos os casos não se esqueça da TAPEvariável de ambiente)

— roaima

11

@ MichaelKjörling inicialmente eu tinha assumido que scpcriaria uma nova conexão para cada arquivo, mas, ao lembrar - e depois de checar novamente tshark-, percebi que estava incorreto. Neste ponto, não sei mais por que os OPs scpdevem demorar tanto tempo por arquivo.

— roaima

@roaima, interessante, obrigado. Eu nunca notei stdin / stdout não sendo o padrão até agora. O tar do BSD no meu Mac no trabalho não menciona um env var TAPE em sua página de manual, embora o tar do GNU na minha máquina Linux o faça.

— tremby

15

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

Se você observar com atenção, verá que a taxa de transferência neste caso é size_of_the_file / s.

Para transferir arquivos com mais eficiência, junte-os tare transfira o tarball:

tar cvf myarchive.tar cap_20151023T*.png

ou, se você também deseja compactar o arquivo morto,

tar cvzf myarchive.tar.gz myfile*

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

— dr01
fonte

PNGs usam deflate, e compactá-los também é inútil.

— Arthur2e5

Eu digo isso porque comprimir o alcatrão não tem efeitos negativos quando os arquivos não podem ser mais comprimidos que é uma boa prática para apenas colocar-z

— Centimane

11

@ Dave, se não puderem ser compactados, ou se a rede for rápida, isso diminuirá a velocidade.

— 23415 Davidmh

@ Davididmh isso seria por uma quantidade significativa embora? Eu pensaria que a compactação de um arquivo já compactado seria bastante rápida, pois realmente examinaria o que poderia compactar e descobrirá que não é nada. Depende Eu acho que se tarfaz normalmente uma segunda passagem para compressão ou se seria a compressão e arquivamento, ao mesmo tempo

— Centimane

3

@Dave no meu caso (dados em um HD moderno de 7000 rpm, CPU de ponta, rede muito rápida, sem se gabar), o tar sem compactação é puramente vinculado à IO, mas com a -zCPU vinculado e muito mais lento. O gzip sempre tentará compactar, daí a desaceleração; afinal, você não pode dizer se uma sequência de bytes é compactável até ter tentado compactá-la. Na minha configuração, mesmo ao transferir arquivos de texto sem formatação, o rsync sem compactação é o mais rápido em um fator de 2 a 3 em comparação com a compactação mais leve. Claro, YMMV.

— 23415 Davidmh

6

Outro motivo pelo qual o scp é mais lento do que deveria ser, especialmente em redes de alta largura de banda, é que ele possui buffers de controle de fluxo interno definidos estaticamente, que acabam se tornando gargalos no desempenho da rede.

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

— Menno Smits
fonte

5

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

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 o tar para reunir o arquivo ou arquivos. Em seguida, usa pigz para obter muitos threads de CPU para compactar e enviar o arquivo; a transmissão de rede está usando o netcat. No lado do recebimento, o netcat ouve e descompacta (em paralelo) e desarma.

— Freiheit
fonte

3

ncnão está criptografado. Adicione um pouco de ssh -Dmagia, talvez?

— Arthur2e5

Isso é realmente muito brilhante

— Jabran Saeed

5

Só tive esse problema ao fazer uma transferência site a site de um grande arquivo mp4 via scp. Estava recebendo ~ 250KB / s. Depois de desativar a proteção contra inundação UDP (FP) no firewall de destino, a taxa de transferência aumentou para 6,5 MB / s. Ao reativar o FP, a taxa caiu para ~ 250 KB / s.

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

Para que o SSH usa o UDP? @ superuser.com - Não é diretamente do que eu leio.

Ao revisar o log do firewall, a detecção de inundação estava ocorrendo nas portas de origem e de destino 4500 nos endereços IP públicos, não nos endereços VPN internos de site a site privados. Portanto, parece que meu problema é provavelmente uma situação NAT Transversal em que os scpdados TCP são criptografados e encapsulados em pacotes ESP e UDP e, consequentemente, sujeitos a FP. Para remover scpda equação, executei uma operação de cópia de arquivo do Windows na VPN e notei um desempenho semelhante ao scpcom e sem o FP ativado. Também executou um iperfteste no TCP e notou 2Mbits / s com FP e 55Mbits / s sem.

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

— bvj
fonte