Warum ist mein rsync so langsam?

Mein Laptop und meine Workstation sind beide mit einem Gigabit-Switch verbunden. Beide laufen unter Linux. Aber wenn ich Dateien mit kopiere rsync, ist die Leistung schlecht.

Ich bekomme ungefähr 22 MB / s. Sollte ich theoretisch nicht etwa 125 MB / s erreichen? Was ist hier der limitierende Faktor?

EDIT: Ich habe einige Experimente durchgeführt.

Schreibe Performance auf den Laptop

Der Laptop verfügt über ein XFS-Dateisystem mit vollständiger Festplattenverschlüsselung. Es verwendet den aes-cbc-essiv:sha256Verschlüsselungsmodus mit einer Schlüssellänge von 256 Bit. Die Schreibgeschwindigkeit der Festplatte beträgt 58,8 MB / s .

iblue@nerdpol:~$ LANG=C dd if=/dev/zero of=test.img bs=1M count=1024
1073741824 Bytes (1.1 GB) copied, 18.2735 s, 58.8 MB/s

Leseleistung auf der Workstation

Die von mir kopierten Dateien befinden sich auf einem Software-RAID-5 über 5 Festplatten. Oben auf dem Überfall ist ein Lvm. Das Volume selbst wird mit derselben Verschlüsselung verschlüsselt. Die Workstation verfügt über eine FX-8150-CPU mit einem nativen AES-NI-Befehlssatz, der die Verschlüsselung beschleunigt. Die Leseleistung der Festplatte beträgt 256 MB / s (Cache war kalt).

iblue@raven:/mnt/bytemachine/imgs$ dd if=backup-1333796266.tar.bz2 of=/dev/null bs=1M
10213172008 bytes (10 GB) copied, 39.8882 s, 256 MB/s

Netzwerkleistung

Ich ließ iperf zwischen den zwei Klienten laufen. Die Netzwerkleistung beträgt 939 Mbit / s

iblue@raven $ iperf -c 94.135.XXX
------------------------------------------------------------
Client connecting to 94.135.XXX, TCP port 5001
TCP window size: 23.2 KByte (default)
------------------------------------------------------------
[  3] local 94.135.XXX port 59385 connected with 94.135.YYY port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.09 GBytes   939 Mbits/sec

Eine andere Möglichkeit, die hohe CPU-Auslastung zu verringern und dennoch die Funktionalität von rsync beizubehalten, besteht darin, von rsync / SSH zu rsync / NFS zu wechseln. Sie können die Pfade, aus denen Sie kopieren möchten, über NFS exportieren und dann rsync lokal vom NFS-Mount an Ihren Zielspeicherort verwenden.

In einem Test von einer WD MyBook Live-Netzwerkfestplatte kopierten ein oder mehrere Rsyncs vom NAS in einem Gigabit-Netzwerk auf zwei lokale USB-Festplatten nach dem Export nicht mehr als 10 MB / s (CPU: 80% usr, 20% sys) NFS und Rsyncing lokal von der NFS-Freigabe auf beide Festplatten Ich habe insgesamt 45 MB / s (bei maximaler Nutzung beider USB2-Festplatten) und wenig CPU-Auslastung. Die Festplattenauslastung bei Verwendung von rsync / SSH betrug ungefähr 6% und bei Verwendung von rsync / NFS eher 24%, während beide USB2-Festplatten nahezu 100% erreichten.

Wir haben also den Engpass von der NAS-CPU auf beide USB2-Festplatten verschoben.

Gründe können sein: Komprimierung, Verschlüsselung, Anzahl und Größe der zu kopierenden Dateien, E / A-Funktionen Ihres Quell- und Zielsystems, TCP-Overhead ... Dies sind alles Faktoren, die die Art der von Ihnen durchgeführten Übertragung beeinflussen können.

Stellen Sie den von Ihnen verwendeten Befehl rsync bereit und geben Sie Details zu den Spezifikationen beider Computer an.

Bearbeiten: Die Verschlüsselung ist häufig ein begrenzender Faktor für die Rsync-Geschwindigkeit. Sie können mit ssh und einer leichteren Verschlüsselung wie ausgeführt werdenarcfour

So etwas wie: rsync -e "ssh -c arcfour"

Oder Sie können ein modifiziertes rsync / ssh verwenden, das die Verschlüsselung deaktivieren kann. Siehe hpn-ssh: http://psc.edu/networking/projects/hpn-ssh

Aber auch hier hat Ihr Laptop im Vergleich zu Ihrer Workstation eine langsame Festplatte. Schreibvorgänge werden möglicherweise blockiert und warten darauf, dass E / A auf Ihren Laptop übertragen werden. Was sind Ihre wirklichen Leistungserwartungen?

Nach einigen weiteren Tests fand ich schließlich selbst die Antwort. rsyncverwendet standardmäßig das Tunneling über ssh. Die Krypto macht es langsam. Also musste ich dieses Krypto-Zeug umgehen.

Lösung 1: Einrichten eines Rsync-Servers

Um es über das rsyncProtokoll zu nutzen, müssen Sie einen rsyncd-Server einrichten. Auf /etc/init.d/rsyncmeinem Laptop befand sich ein Skript, also schätzte ich, dass rsyncd ausgeführt wurde. Ich lag falsch. /etc/init.d/rsync startexistiert stillschweigend, wenn in rsync nicht aktiviert ist /etc/default/rsync. Dann müssen Sie es auch konfigurieren /etc/rsyncd.conf, was ein Schmerz ist.

Wenn Sie dies alles erledigen, müssen Sie verwenden rsync file.foo user@machine::directory. Bitte beachten Sie, dass es zwei Doppelpunkte gibt .

Lösung 2: Old-School-RSH-Server

Die Konfiguration war mir jedoch viel zu kompliziert. Also habe ich gerade und rsh-serverauf meinem Laptop installiert . Beim Aufrufen von rsync auf der Workstation wird -e rexecdann rsh anstelle von ssh verwendet. Das hat dann die Leistung auf 44,6 MB / s fast verdoppelt , was immer noch langsam ist. Die Geschwindigkeit springt zwischen 58 MB / s und 33 MB / s , was darauf hinweist, dass möglicherweise Probleme mit der Puffer- oder Überlastungskontrolle vorliegen. Dies würde den Rahmen dieser Frage sprengen.

Dies sind sehr alte Fragen und Antworten, aber eine wichtige Sache fehlt: Wenn Sie bereits komprimierte oder verschlüsselte Daten kopieren, deaktivieren Sie die Komprimierung.

Wenn Ihre Daten weder komprimiert noch verschlüsselt sind, möchten Sie sie dennoch nur einmal komprimieren! Rsync komprimiert mit -z, ssh komprimiert mit -C (möglicherweise standardmäßig). Ich habe nicht getestet, was besser ist, da meine Daten komprimiert sind.

Während ich gerade dabei bin, können Sie die X-Weiterleitung und die TTY-Zuweisung deaktivieren. Dies führt zu folgenden Ergebnissen:

rsync -avh -e "ssh -x -T -c arcfour -o Compression=no" $src $dst

Vergewissern iptrafSie sich abschließend (zum Beispiel mit ), dass Sie tatsächlich die Netzwerkschnittstelle verwenden, von der Sie glauben, dass Sie sie verwenden. Ich muss zu meiner großen Überraschung feststellen, dass auf meinem OSX der ausgehende SSH an die IP auf der Standardausgangsschnittstelle gebunden war, anstatt an die IP auf der Schnittstelle, auf der die Pakete weitergeleitet werden sollten. Meine direkte GB-Querverbindung zwischen zwei Laptops, die ebenfalls über WLAN verbunden waren, wurde nicht verwendet. Nach einer Untersuchung lag es daran, dass der Mac 169.254 / 16 für alle Schnittstellen verwendet und der Zielcomputer auf ARP-Anforderungen antwortet, obwohl die Anforderung über eine andere Schnittstelle eingegangen ist.