Perché SCP è così lento e come renderlo più veloce?

59

Sto cercando di copiare un batch di file con scpma è molto lento. Questo è un esempio con 10 file:

$ 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

La cosa strana è che la velocità di trasferimento è di circa 413 KB / se la dimensione del file è di circa 413 KB, quindi in realtà dovrebbe trasferire un file al secondo, ma richiede circa 4,3 secondi per file.

Qualche idea da dove provenga questo sovraccarico, e c'è un modo per renderlo più veloce?

scp time batch-jobs

— laurent
fonte

3

Quale velocità ti aspetti (ovvero, esiste un altro protocollo che mostra velocità di trasferimento più elevate tra le stesse due macchine)? Cosa succede quando scp un file molto più grande (forse la concatenazione di tutti i tuoi file da 413 KB)?

— Dhag,

6

Sembra che il sistema remoto stia tentando di risolvere l'indirizzo IP del client in un nome e si deve attendere un timeout prima che la sessione proceda. Potresti indagare su come risolverlo (ad esempio aggiungi il tuo indirizzo IP al file / etc / hosts della destinazione).

— wurtel,

4

Vale la pena ricordare che il flag -C consente la compressione durante il trasferimento. Sebbene il tuo problema sembri essere il trasferimento iniziale dei costi, la compressione è sostanzialmente "libera" e quasi sempre aiuta.

— Sam,

@wurtel: non vedo quello che vedi, tutto ciò che vedo sono i tempi. Dovrebbe essere comunque necessaria una sola chiamata DNS inversa.

— James Reinstate Monica Polk,

Ti affidi a SCP per motivi di sicurezza o solo per la copia remota?

— Freiheit,

17

Il commento di @ wurtel è probabilmente corretto: ci sono molte spese generali che stabiliscono ogni connessione. Se riesci a risolvere il problema , otterrai trasferimenti più veloci (e se non puoi, usa semplicemente la rsyncsoluzione alternativa di @ roaima ). Ho fatto un esperimento per trasferire file di dimensioni simili ( head -c 417K /dev/urandom > foo.1e ho fatto alcune copie di quel file) a un host che impiega un po 'di tempo a connettersi (HOST4) e uno che risponde molto 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
$

1

Grazie, è molto interessante. L'output di scp è un po 'rotto se mostra lo stesso tempo anche se è completamente diverso da un host all'altro. Dovrebbero probabilmente includere il tempo di connessione nel tempo totale.

— Laurent,

1

Quindi la tua ipotesi è che crea una nuova connessione una volta per ogni file?

— rogerdpack,

59

È possibile utilizzare rsync(over ssh), che utilizza una singola connessione per trasferire tutti i file di origine.

rsync -avP cap_* user@host:dir

Se non si dispone di rsync(e perché no !?) è possibile utilizzare tarcon sshcome questo, che evita la creazione di un file temporaneo:

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

È rsyncpreferibile, a parità di altre condizioni, perché è riavviabile in caso di interruzione.

— roaima
fonte

6

Stai dicendo che una singola scpchiamata non userebbe una singola connessione per trasferire tutti i file?

— un CVn del

1

Nel caso di tarpipe, non è necessario per f -ogni lato, poiché tar emette / legge da stdout / stdin per impostazione predefinita. Quindi tar cz cap_* | ssh user@host tar xvzC dirlo farebbe.

— tremby,

1

@tremby non necessariamente. tarpuò essere compilato con diversi valori predefiniti (vedi tar --show-defaultsse stai usando GNU tar, o /etc/default/taraltrimenti, e in entrambi i casi non dimenticare la TAPEvariabile di ambiente)

— roaima

1

@ MichaelKjörling inizialmente avevo pensato che scpavrebbe creato una nuova connessione per ogni file, ma al ricordo - e dopo aver ricontrollato con tshark- mi sono reso conto che non ero corretto. A questo punto non sono più sicuro del motivo per cui gli OP scpdovrebbero impiegare così tanto tempo per file.

— roaima,

@roaima, interessante, grazie. Non ho mai notato che stdin / stdout non sono stati predefiniti finora. Il tar BSD sul mio Mac al lavoro non menziona un TAPE env var nella sua pagina man, anche se il tar GNU sulla mia macchina Linux lo fa.

— tremby,

15

È la negoziazione del trasferimento che richiede tempo. In generale, le operazioni su n file di b byte richiedono molto più tempo di una singola operazione su un singolo file di n * b byte. Questo vale anche ad esempio per l'I / O del disco.

Se osservi attentamente, vedrai che la velocità di trasferimento in questo caso è size_of_the_file / secs.

Per trasferire i file in modo più efficiente, raggruppali insieme tar, quindi trasferisci il tarball:

tar cvf myarchive.tar cap_20151023T*.png

oppure, se si desidera comprimere anche l'archivio,

tar cvzf myarchive.tar.gz myfile*

La compressione o meno dipende dal contenuto del file, ad es. se sono JPEG o PNG, la compressione non avrà alcun effetto.

— DR01
fonte

I PNG usano deflate e anche decomprimerli è inutile.

— Arthur2e5,

Direi che poiché comprimere il tar non ha effetti negativi quando i file non possono essere compressi ulteriormente, è una buona pratica semplicemente mettere-z

— Centimane

1

@Dave se non possono essere compressi, o la rete è veloce, rallenterà le cose.

— Davidmh,

@Davidmh sarebbe questo in una quantità significativa però? Penserei che comprimere un file già compresso sarebbe abbastanza veloce in quanto guarderebbe semplicemente cosa potrebbe comprimere e scoprire che non è niente. Dipende dal fatto che tarnormalmente esegua un secondo passaggio per la compressione o se comprimesse e archiviasse allo stesso tempo

— Centimane,

3

@Dave nel mio caso (dati su un moderno HD da 7000 rpm, CPU di fascia alta, rete molto veloce, non vantarsi affatto), tar senza compressione è puramente legato a IO, ma con -zCPU è molto più lento. gzip proverà sempre a comprimere, quindi il rallentamento; dopo tutto, non si può dire se una stringa di byte è comprimibile fino a quando non si è tentato di comprimerlo. Nella mia configurazione, anche quando si trasferiscono file di testo semplice, rsync senza compressione è il più veloce di un fattore 2-3 rispetto alla compressione più leggera. Certo, YMMV.

— Davidmh,

6

Un altro motivo per cui scp è più lento di quanto dovrebbe essere, specialmente su reti ad alta larghezza di banda, è che ha buffer di controllo del flusso interno definiti staticamente che finiscono per diventare colli di bottiglia nelle prestazioni della rete.

HPN-SSH è una versione con patch di OpenSSH che aumenta le dimensioni di questi buffer. Fa una grande differenza per la velocità di trasferimento scp (vedi le tabelle sul sito, ma parlo anche per esperienza personale). Ovviamente, per ottenere i vantaggi è necessario installare HPN-SSH su tutti i host, ma ne vale la pena se è necessario trasferire regolarmente file di grandi dimensioni.

— Menno Smits
fonte

5

Ho usato la tecnica qui descritta che utilizza gzip e netcat paralleli per comprimere e copiare rapidamente i dati.

Si riduce 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 /

Questo usa tar per raccogliere il file o i file. Quindi utilizza pigz per ottenere molti thread cpu per comprimere e inviare il file, la trasmissione di rete utilizza netcat. Sul lato ricevente, netcat ascolta quindi decomprime (in parallelo) e non lo fa.

— Freiheit
fonte

3

ncnon è crittografato. Aggiungi un po 'di ssh -Dmagia forse?

— Arthur2e5,

questo è in realtà abbastanza brillante

— Jabran Saeed

5

Ho appena avuto questo problema facendo un trasferimento da sito a sito di un file mp4 di grandi dimensioni tramite scp. Stava ottenendo ~ 250 KB / s. Dopo aver disabilitato la protezione dalle inondazioni UDP (FP) sul firewall di destinazione, la velocità di trasferimento è aumentata a 6,5 MB / s. Quando si riaccende FP, la frequenza è tornata a ~ 250 KB / s.

Mittente: cygwin, Ricevitore: Fedora 20, Firewall Sophos UTM.

Per cosa usa SSH UDP? @ superuser.com - Non direttamente da quello che ho letto.

Nel rivedere il registro del firewall, il rilevamento delle inondazioni si stava verificando su entrambe le porte di origine e destinazione 4500 sugli indirizzi IP pubblici, non sugli indirizzi VPN interni da sito a sito privati. Quindi sembra che il mio problema sia probabilmente una situazione NAT Traversal in cui i scpdati TCP sono in definitiva crittografati e incapsulati in pacchetti ESP e UDP e di conseguenza soggetti a FP. Per rimuovere scpdall'equazione, ho eseguito un'operazione di copia dei file di Windows attraverso la VPN e ho notato prestazioni simili a quelle scpcon e senza FP abilitato. Ha anche eseguito un iperftest su TCP e notato 2Mbit / sec con FP e 55Mbit / sec senza.

Come funziona NAT-T con IPSec? @ cisco.com

— BVJ
fonte