Warum ist scp so langsam und wie kann man es schneller machen?

59

Ich versuche, einen Stapel von Dateien mit zu kopieren, scpaber es ist sehr langsam. Dies ist ein Beispiel mit 10 Dateien:

$ 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

Das Seltsame ist, dass die Übertragungsrate etwa 413 KB / s und die Dateigröße etwa 413 KB beträgt. Daher sollte wirklich eine Datei pro Sekunde übertragen werden, es dauert jedoch etwa 4,3 Sekunden pro Datei.

Irgendeine Idee, woher dieser Overhead kommt, und gibt es eine Möglichkeit, ihn schneller zu machen?

scp time batch-jobs

— laurent
quelle

3

Welche Geschwindigkeit erwarten Sie (dh gibt es ein anderes Protokoll, das höhere Übertragungsgeschwindigkeiten zwischen denselben beiden Computern anzeigt)? Was passiert, wenn Sie eine viel größere Datei scp (möglicherweise die Verkettung aller Ihrer 413 KB-Dateien)?

— Dhag

6

Möglicherweise versucht das Remote-System, die Client-IP-Adresse in einen Namen aufzulösen, und Sie müssen auf eine Zeitüberschreitung warten, bevor die Sitzung fortgesetzt wird. Sie können das Problem beheben (z. B. indem Sie Ihre IP-Adresse zur Datei / etc / hosts des Ziels hinzufügen).

— Wurtel

4

Erwähnenswert ist, dass das Flag -C die Komprimierung während der Übertragung ermöglicht. Obwohl das Problem beim Starten von Übertragungen zu sein scheint, ist die Komprimierung grundsätzlich "kostenlos" und hilft fast immer.

— Sam

@wurtel: Ich sehe nicht was du siehst, alles was ich sehe sind Zeiten. Es sollte sowieso nur ein einziger Reverse-DNS-Aufruf erforderlich sein.

— James K Polk

Verlassen Sie sich aus Sicherheitsgründen auf SCP oder nur auf das Kopieren per Fernzugriff?

— Freiheit

17

@wurtels Kommentar ist wahrscheinlich richtig: Es gibt eine Menge Overhead beim Herstellen jeder Verbindung. Wenn Sie das beheben können, erhalten Sie schnellere Übertragungen (und wenn nicht, verwenden Sie einfach die Problemumgehung von @ roaima rsync). Ich habe ein Experiment durchgeführt, bei dem Dateien mit ähnlicher Größe ( head -c 417K /dev/urandom > foo.1und einige Kopien dieser Datei) auf einen Host übertragen wurden, dessen Verbindung eine Weile dauert (HOST4) und der sehr schnell reagiert (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
$

— Drewbenn
quelle

1

Danke, das ist sehr interessant. Die scp-Ausgabe ist irgendwie kaputt, wenn sie zur selben Zeit angezeigt wird, obwohl sie sich von Host zu Host völlig unterscheidet. Sie sollten wahrscheinlich die Verbindungszeit in die Gesamtzeit einbeziehen.

— Laurent

1

Ihre Hypothese lautet also, dass für jede Datei eine neue Verbindung hergestellt wird?

— Rogerdpack

59

Sie könnten rsync(over ssh) verwenden, das eine einzige Verbindung verwendet, um alle Quelldateien zu übertragen.

rsync -avP cap_* user@host:dir

Wenn Sie nicht haben rsync(und warum !? nicht) können Sie verwenden , tarmit sshwie diese, die eine temporäre Datei vermeidet erstellen:

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

Das rsyncist vorzuziehen, alle anderen Dinge sind gleich, da es im Falle einer Unterbrechung neu gestartet werden kann.

— Roaima
quelle

6

Wollen Sie damit sagen, dass ein einzelner scpAufruf nicht eine einzige Verbindung zum Übertragen aller Dateien verwenden würde?

— ein Lebenslauf vom

1

Im Tarpipe-Fall ist das f -auf jeder Seite nicht erforderlich , da tar standardmäßig nach stdout / stdin ausgibt / von dort liest. tar cz cap_* | ssh user@host tar xvzC dirWürde es also tun.

— Tremby

1

@tremby nicht unbedingt. tarkann mit verschiedenen Standardwerten kompiliert werden (sehen tar --show-defaultsSie, ob Sie GNU tar verwenden oder /etc/default/tarnicht, und vergessen Sie in beiden Fällen die TAPEUmgebungsvariable nicht)

— roaima

1

@ MichaelKjörling anfangs war ich davon ausgegangen, dass scpfür jede datei eine neue verbindung erstellt werden würde, aber bei der erinnerung - und nach zweimaliger überprüfung mit tshark- stellte ich fest, dass ich falsch war. Zu diesem Zeitpunkt bin ich mir nicht mehr sicher, warum die OPs scppro Datei so lange dauern sollten.

— Roaima

@roaima, interessant, danke. Ich habe noch nie bemerkt, dass stdin / stdout noch nicht Standard ist. BSD tar auf meinem Mac bei der Arbeit erwähnt in seiner Manpage kein TAPE env var, GNU tar auf meinem Linux-Rechner jedoch.

— Tremby

15

Es ist die Aushandlung des Transfers, die Zeit braucht. Im Allgemeinen dauern Operationen an n Dateien mit jeweils b Bytes viel, viel länger als eine einzelne Operation an einer einzelnen Datei mit n * b Bytes. Dies gilt auch zB für Disk I / O.

Wenn Sie genau hinschauen, werden Sie feststellen, dass die Übertragungsrate in diesem Fall die Größe der Datei / s beträgt .

Um Dateien effizienter zu übertragen, bündeln Sie sie mit tarund übertragen Sie dann den Tarball:

tar cvf myarchive.tar cap_20151023T*.png

oder, wenn Sie auch das Archiv komprimieren möchten,

tar cvzf myarchive.tar.gz myfile*

Ob komprimiert werden soll oder nicht, hängt vom Dateiinhalt ab, z. Wenn es sich um JPEGs oder PNGs handelt, hat die Komprimierung keine Auswirkung.

— dr01
quelle

PNGs verwenden deflate, und es ist auch sinnlos, sie zu komprimieren.

— Arthur2e5

Ich würde sagen , dass , weil die TAR - Komprimierung keine negativen Auswirkungen hat , wenn die Dateien nicht weiter komprimiert werden , ist es eine gute Praxis, nur setzen-z

— Centimane

1

@ Dave, wenn sie nicht komprimiert werden können oder das Netzwerk schnell ist, wird es die Dinge verlangsamen.

— Davidmh

@Davidmh wäre dies jedoch eine erhebliche Menge? Ich würde denken, dass das Komprimieren einer bereits komprimierten Datei ziemlich schnell sein würde, da es wirklich nur darüber nachdenken würde, was es komprimieren könnte und feststellen würde, dass es nichts ist. Hängt davon ab, ob tarnormalerweise ein zweiter Durchgang für die Komprimierung ausgeführt wird oder ob gleichzeitig komprimiert und archiviert wird

— Centimane,

3

@ Dave in meinem Fall (Daten auf einer modernen 7000 U / min HD, High-End-CPU, sehr schnelles Netzwerk, überhaupt nicht prahlen), Teer ohne Komprimierung ist rein IO-gebunden, aber mit -zCPU-gebunden und viel langsamer. gzip versucht immer zu komprimieren, daher die Verlangsamung; Schließlich können Sie nicht feststellen, ob eine Zeichenfolge von Bytes komprimierbar ist, bis Sie versucht haben, sie zu komprimieren. In meiner Konfiguration ist rsync ohne Komprimierung selbst beim Übertragen von Nur-Text-Dateien um den Faktor 2-3 schneller als die leichteste Komprimierung. Natürlich YMMV.

— Davidmh

6

Ein weiterer Grund dafür, dass scp langsamer ist als es sein sollte, insbesondere in Netzwerken mit hoher Bandbreite, besteht darin, dass statisch definierte interne Puffer zur Flusskontrolle vorhanden sind, die zu Engpässen bei der Netzwerkleistung führen.

HPN-SSH ist eine gepatchte Version von OpenSSH, die die Größe dieser Puffer erhöht. Die Übertragungsgeschwindigkeit von scp ändert sich massiv (siehe die Grafiken auf der Website, aber ich spreche auch aus eigener Erfahrung). Natürlich müssen Sie HPN-SSH auf allen Ihren Hosts installieren, um die Vorteile zu nutzen. Es lohnt sich jedoch, wenn Sie regelmäßig große Dateien übertragen müssen.

— Menno Smits
quelle

5

Ich habe die hier beschriebene Technik verwendet, die paralleles gzip und Netcat verwendet, um Daten schnell zu komprimieren und zu kopieren.

Es läuft auf Folgendes hinaus:

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

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

Dies verwendet tar, um die Datei oder die Dateien zu sammeln. Verwenden Sie dann pigz, um viele CPU-Threads zum Komprimieren und Senden der Datei abzurufen. Die Netzwerkübertragung erfolgt über netcat. Auf der Empfängerseite lauscht netcat und dekomprimiert (parallel) und entpackt.

— Freiheit
quelle

3

ncist nicht verschlüsselt. ssh -DVielleicht etwas Magie hinzufügen?

— Arthur2e5

das ist eigentlich ziemlich genial

— Jabran Saeed

5

Hatte gerade dieses Problem eine Site-to-Site-Übertragung einer großen mp4-Datei über scp. Bekam ~ 250KB / s. Nach dem Deaktivieren des UDP-Flood-Schutzes (FP) auf der Ziel-Firewall stieg die Übertragungsrate auf 6,5 MB / s. Beim Wiedereinschalten von FP fiel die Rate auf ~ 250 KB / s zurück.

Absender: cygwin, Empfänger: Fedora 20, Firewall Sophos UTM.

Wofür verwendet SSH UDP? @ superuser.com - Es geht nicht direkt um das, was ich gelesen habe.

Bei der Überprüfung des Firewall-Protokolls wurde eine Überflutungserkennung sowohl an den Quell- als auch an den Zielports 4500 über die öffentlichen IP-Adressen und nicht über die internen VPN-Adressen von privatem Standort zu Standort durchgeführt. Es scheint also, dass es sich bei meinem Problem wahrscheinlich um eine NAT-Traversal-Situation handelt, in der die scpTCP-Daten letztendlich verschlüsselt und in ESP- und UDP-Paketen gekapselt sind und folglich der FP unterliegen. Um scpmich von der Gleichung zu entfernen , habe ich einen Windows-Dateikopiervorgang über das VPN ausgeführt und eine ähnliche Leistung wie scpmit und ohne aktiviertem FP festgestellt . iperfLief auch einen Test über TCP und bemerkte 2 Mbit / s mit FP und 55 Mbit / s ohne.

Wie funktioniert NAT-T mit IPSec? @ cisco.com

— bvj
quelle