it-swarm.com.de

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 rsync kopiere, funktioniert es schlecht.

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

EDIT : Ich habe einige Experimente durchgeführt.

Schreiben Sie die Leistung auf den Laptop

Der Laptop verfügt über ein xfs-Dateisystem mit vollständiger Festplattenverschlüsselung. Es verwendet aes-cbc-essiv:sha256 Verschlüsselungsmodus mit 256 Bit Schlüssellänge. Die Schreibleistung der Festplatte beträgt 58,8 MB/s.

[email protected]:~$ 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

Lesen Sie die Leistung auf der Workstation

Die Dateien, die ich kopiert habe, befinden sich auf einem Software-RAID-5 über 5 Festplatten. Oben auf dem Überfall befindet sich ein Level. Das Volume selbst wird mit derselben Chiffre 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).

[email protected]:/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 habe iperf zwischen den beiden Clients ausgeführt. Die Netzwerkleistung beträgt 939 Mbit/s

[email protected] $ 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
45
iblue

Eine andere Möglichkeit, die hohe CPU-Auslastung zu verringern und gleichzeitig die Funktionalität von rsync beizubehalten, besteht darin, von rsync/SSH zu rsync/NFS zu wechseln. Sie können die Pfade, von 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 würden ein oder mehrere Rsyncs von NAS in einem Gigabit-Netzwerk auf zwei lokale USB-Festplatten) nicht mehr als 10 MB/s kopieren (CPU: 80% usr , 20% sys), nachdem ich über NFS exportiert und lokal von der NFS-Freigabe auf beide Festplatten synchronisiert hatte, erhielt ich insgesamt 45 MB/s (maximal beide USB2-Festplatten) und wenig CPU-Auslastung. Die Festplattenauslastung bei Verwendung von rsync/SSH betrug etwa 6 % und die Verwendung von rsync/NFS lag näher bei 24%, während beide USB2-Festplatten nahe bei 100% lagen.

Daher haben wir den Engpass effektiv von der NAS CPU) auf beide USB2-Festplatten verschoben.

19
Dag Wieers

Gründe können sein: Komprimierung, Verschlüsselung, Anzahl und Größe der zu kopierenden Dateien, Festplatten-E/A-Funktionen Ihres Quell- und Zielsystems, TCP Overhead ... Dies sind alles Faktoren, die Einfluss haben können die Art der Übertragung, die Sie durchführen.

Bitte senden Sie den von Ihnen verwendeten Befehl rsync 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üsselungsverschlüsselung wie arcfour arbeiten

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 ein langsames Laufwerk. Schreibvorgänge werden möglicherweise blockiert und warten darauf, dass E/A an Ihren Laptop gesendet werden. Was sind Ihre tatsächlichen Leistungserwartungen?

28
ewwhite

Nach einigen weiteren Tests fand ich die Antwort endlich selbst. rsync verwendet standardmäßig das Tunneln über ssh. Die Krypto macht es langsam. Also musste ich das Krypto-Zeug umgehen.

Lösung 1: Einrichten eines Rsync-Servers

Um es über das Protokoll rsync zu verwenden, müssen Sie einen rsyncd-Server einrichten. Auf meinem Laptop befand sich ein /etc/init.d/rsync - Skript, also wurde rsyncd ausgeführt. Ich lag falsch. /etc/init.d/rsync start Existiert stillschweigend, wenn rsync in /etc/default/rsync Nicht aktiviert ist. Dann müssen Sie es auch in /etc/rsyncd.conf Konfigurieren, was sehr schmerzhaft ist.

Wenn Sie dies alles erledigen, müssen Sie rsync file.foo [email protected]::directory Verwenden. 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 rsh-server Auf meinem Laptop installiert. Wenn Sie rsync auf der Workstation mit -e rexec Aufrufen, wird rsh anstelle von ssh verwendet. Das verdoppelte dann fast die Leistung auf 44,6 MB/s, was immer noch langsam ist. Die Geschwindigkeit springt zwischen 58 MB/s und 33 MB/s , Dies weist darauf hin, dass möglicherweise Probleme mit der Puffer- oder Überlastungskontrolle vorliegen. Das geht aber über den Rahmen dieser Frage hinaus.

10
iblue

Dies sind sehr alte Fragen und Antworten, aber eines 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 trotzdem 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:

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

Stellen Sie schließlich sicher (z. B. mit iptraf), dass Sie tatsächlich die Netzwerkschnittstelle verwenden, von der Sie glauben, dass Sie sie verwenden. Ich habe zu meiner großen Überraschung festgestellt, dass unter meinem OSX das ausgehende SSH an die IP auf der ausgehenden Standardschnittstelle gebunden war und nicht 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 sind, wurde nicht verwendet. Nach der Untersuchung lag es an der Verwendung von 169.254/16, die der Mac auf allen Schnittstellen installiert, und dem Zielcomputer, der auf ARP-Anfragen antwortete, obwohl die Anfrage auf einer anderen Schnittstelle einging.

2
Law29