¿Por qué scp es tan lento y cómo hacerlo más rápido?

59

Estoy tratando de copiar un lote de archivos scppero es muy lento. Este es un ejemplo con 10 archivos:

$ 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

Lo extraño es que la velocidad de transferencia es de aproximadamente 413 KB / sy el tamaño del archivo es de aproximadamente 413 KB, por lo que realmente debería transferir un archivo por segundo, sin embargo, tarda unos 4,3 segundos por archivo.

¿Alguna idea de dónde proviene esta sobrecarga y hay alguna forma de hacerlo más rápido?

scp time batch-jobs

— Laurent
fuente

3

¿Qué velocidad espera (es decir, hay otro protocolo que muestre velocidades de transferencia más altas entre las mismas dos máquinas)? ¿Qué sucede cuando scp un archivo mucho más grande (tal vez la concatenación de todos sus archivos de 413 KB)?

— dhag

66

Parece que el sistema remoto puede estar tratando de resolver la dirección IP del cliente a un nombre, y tiene que esperar un tiempo de espera antes de que continúe la sesión. Podría investigar la solución de eso (por ejemplo, agregue su dirección IP al archivo / etc / hosts del destino).

— wurtel

44

Vale la pena mencionar que el indicador -C permite la compresión durante la transferencia. Aunque su problema parece ser las transferencias de inicio generales, la compresión es básicamente "gratuita" y casi siempre ayuda.

— Sam

@wurtel: No veo lo que estás viendo, todo lo que veo son tiempos. De todos modos, solo debería necesitarse una única llamada DNS inversa.

— James reinstala a Monica Polk el

¿Confía en SCP por seguridad o solo para la copia remota?

— Freiheit

17

El comentario de @ wurtel probablemente sea correcto: hay mucha sobrecarga estableciendo cada conexión. Si puede solucionarlo , obtendrá transferencias más rápidas (y si no puede hacerlo, simplemente use la rsyncsolución alternativa de @ roaima ). Hice un experimento transfiriendo archivos de tamaño similar ( head -c 417K /dev/urandom > foo.1e hice algunas copias de ese archivo) a un host que tarda un tiempo en conectarse (HOST4) y uno que responde muy rápidamente (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
$

1

Gracias, eso es muy interesante. La salida scp está un poco rota si muestra la misma hora a pesar de que es completamente diferente de un host a otro. Probablemente deberían incluir el tiempo de conexión en el tiempo total.

— Laurent

1

¿Entonces su hipótesis es que hace una nueva conexión una vez para cada archivo?

— rogerdpack

59

Puede usar rsync(over ssh), que usa una sola conexión para transferir todos los archivos de origen.

rsync -avP cap_* user@host:dir

Si usted no tiene rsync(y por qué no !?) se puede utilizar tarcon ssheste tipo, lo que evita la creación de un archivo temporal:

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

El rsynces preferible, siendo todo lo demás igual, porque es reiniciable en el caso de una interrupción.

— roaima
fuente

66

¿Está diciendo que una sola scpinvocación no usaría una sola conexión para transferir todos los archivos?

— un CVn

1

En el caso de tarpipe, no hay necesidad de que esté f -en cada lado, ya que las salidas tar a / lee desde stdout / stdin por defecto. Entonces tar cz cap_* | ssh user@host tar xvzC dirlo haría.

— tembloroso

1

@tremby no necesariamente. tarpuede compilarse con diferentes valores predeterminados (vea tar --show-defaultssi está usando GNU tar, o de lo /etc/default/tarcontrario, y en ambos casos no olvide la TAPEvariable de entorno)

— roaima

1

@ MichaelKjörling inicialmente asumí que eso scpcrearía una nueva conexión para cada archivo, pero al recordarlo, y después de verificarlo dos veces tshark, me di cuenta de que estaba incorrecto. En este punto, ya no estoy seguro de por qué los OP scpdeberían tomar tanto tiempo por archivo.

— roaima

@roaima, interesante, gracias. Nunca he notado que stdin / stdout no sea el predeterminado hasta ahora. El tar de BSD en mi Mac en el trabajo no menciona una variable TAPE env en su página de manual, aunque el tar de GNU en mi máquina Linux sí.

— temblorosa

15

Es la negociación de la transferencia lo que lleva tiempo. En general, las operaciones en n archivos de b bytes cada una lleva mucho, mucho más tiempo que una sola operación en un solo archivo de n * b bytes. Esto también es cierto, por ejemplo, para E / S de disco.

Si observa detenidamente, verá que la velocidad de transferencia en este caso es size_of_the_file / secs.

Para transferir archivos de manera más eficiente, agrúpelos tary luego transfiera el tarball:

tar cvf myarchive.tar cap_20151023T*.png

o, si también quieres comprimir el archivo,

tar cvzf myarchive.tar.gz myfile*

Si se comprime o no depende del contenido del archivo, por ejemplo. si son JPEG o PNG, la compresión no tendrá ningún efecto.

— dr01
fuente

Los PNG usan desinflar, y comprimirlos tampoco tiene sentido.

— Arthur2e5

Diría que porque comprimir el alquitrán no tiene efectos negativos cuando los archivos no se pueden comprimir más, es una buena práctica simplemente ponerlo-z

— Centimane

1

@Dave si no se pueden comprimir o si la red es rápida, ralentizará las cosas.

— Davidmh

@Davidmh, ¿sería esto por una cantidad significativa? Creo que comprimir un archivo ya comprimido sería bastante rápido, ya que realmente solo miraría sobre lo que podría comprimir y descubriría que no es nada. Depende, supongo, si tarnormalmente hace una segunda pasada para la compresión o si estaría comprimiendo y archivando al mismo tiempo

— Centimane

3

@Dave en mi caso (datos en un HD moderno de 7000 rpm, CPU de alta gama, red muy rápida, sin alardear en absoluto), el alquitrán sin compresión está limitado a E / S, pero -zestá vinculado a la CPU y es mucho más lento. gzip siempre intentará comprimir, de ahí la ralentización; después de todo, no puede saber si una cadena de bytes es compresible hasta que haya intentado comprimirla. En mi configuración, incluso cuando se transfieren archivos de texto sin formato, rsync sin compresión es el más rápido en un factor de 2-3 en comparación con la compresión más ligera. Por supuesto, YMMV.

— Davidmh

6

Otra razón por la que scp es más lento de lo que debería ser, especialmente en redes de gran ancho de banda, es porque tiene memorias intermedias de control de flujo interno estáticamente definidas que terminan convirtiéndose en cuellos de botella en el rendimiento de la red.

HPN-SSH es una versión parcheada de OpenSSH que aumenta el tamaño de estos búferes. Hace una gran diferencia en la velocidad de transferencia scp (ver los cuadros en el sitio, pero también hablo por experiencia personal). Por supuesto, para obtener los beneficios, necesita instalar HPN-SSH en todos sus hosts, pero vale la pena si necesita transferir regularmente archivos grandes.

— Menno Smits
fuente

5

He usado la técnica descrita aquí que usa gzip y netcat paralelos para comprimir y copiar datos rápidamente.

Se reduce 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 /

Esto usa tar para reunir el archivo o archivos. Luego usa pigz para obtener muchos subprocesos de la CPU para comprimir y enviar el archivo, la transmisión de red está usando netcat. En el lado receptor, netcat escucha y luego descomprime (en paralelo) y untars.

— Freiheit
fuente

3

ncno está encriptado Añadir un poco de ssh -Dmagia tal vez?

— Arthur2e5

esto es realmente bastante brillante

— Jabran Saeed

5

Acabo de tener este problema haciendo una transferencia de sitio a sitio de un gran archivo mp4 a través de scp. Estaba obteniendo ~ 250KB / s. Después de deshabilitar la protección de inundación UDP (FP) en el firewall de destino, la velocidad de transferencia aumentó a 6.5MB / s. Al volver a encender FP, la velocidad volvió a caer a ~ 250 KB / s.

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

¿Para qué utiliza SSH UDP? @ superuser.com : no lo hace directamente de lo que leí.

Al revisar el registro del firewall, se estaba produciendo una detección de inundación en los puertos de origen y destino 4500 a través de las direcciones IP públicas, no en las direcciones VPN internas privadas de sitio a sitio. Por lo tanto, parece que mi problema es una situación de NAT Traversal en la que los scpdatos TCP se encriptan y encapsulan en paquetes ESP y UDP y, en consecuencia, están sujetos a FP. Para eliminar scpde la ecuación, ejecuté una operación de copia de archivos de Windows a través de la VPN y noté un rendimiento similar scpcon y sin FP habilitado. También ejecuté una iperfprueba sobre TCP y noté 2Mbits / seg con FP, y 55Mbits / seg sin.

¿Cómo funciona NAT-T con IPSec? @ cisco.com

— bvj
fuente