Lösung 1:
Gründe können sein:Komprimierung, Verschlüsselung, die Anzahl und Größe der kopierten Dateien, die Festplatten-E/A-Fähigkeiten Ihrer Quell- und Zielsysteme, TCP-Overhead ... Dies sind alles Faktoren, die die Art der von Ihnen durchgeführten Übertragung beeinflussen können.
Bitte posten Sie den von Ihnen verwendeten rsync-Befehl und geben Sie Details zu den Spezifikationen beider Computer an.
Bearbeiten:Die Verschlüsselung ist oft ein begrenzender Faktor bei der Rsync-Geschwindigkeit. Sie können mit ssh und einer leichteren Verschlüsselung wie arcfour laufen
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 sind möglicherweise blockiert und warten darauf, dass E/A-Vorgänge an Ihren Laptop gesendet werden. Was sind Ihre wirklichen Leistungserwartungen?
Lösung 2:
Eine andere Möglichkeit, eine hohe CPU-Auslastung zu mindern, aber dennoch die Funktionalität von rsync beizubehalten, ist der Wechsel von rsync/SSH zu rsync/NFS. Sie könnten die Pfade, von denen Sie kopieren möchten, über NFS exportieren und dann rsync lokal vom NFS-Mount zu Ihrem Zielort verwenden.
In einem Test von einer WD MyBook Live-Netzwerkfestplatte kopierten eine oder mehrere rsyncs vom NAS in einem Gigabit-Netzwerk zu 2 lokalen USB-Festplatten nicht mehr als 10 MB/s (CPU:80 % usr, 20 % sys) nach dem Exportieren NFS und rsync lokal von der NFS-Freigabe auf beide Festplatten, ich habe insgesamt 45 MB/s (bei maximaler Auslastung beider USB2-Festplatten) und wenig CPU-Auslastung. Die Festplattenauslastung bei Verwendung von rsync/SSH betrug etwa 6 % und bei Verwendung von rsync/NFS eher 24 %, während beide USB2-Festplatten nahezu 100 % erreichten.
Also haben wir den Engpass effektiv von der NAS-CPU auf beide USB2-Festplatten verschoben.
Lösung 3:
Nach einigen weiteren Tests fand ich schließlich selbst die Antwort. rsync verwendet standardmäßig Tunneling über ssh. Die Krypto macht es langsam. Also musste ich dieses Krypto-Zeug umgehen.
Lösung 1:Einrichten eines rsync-Servers
Verwenden Sie es über die rsync Protokoll müssen Sie einen rsyncd-Server einrichten. Da war ein /etc/init.d/rsync Skript auf meinem Laptop, also vermutete ich, dass rsyncd ausgeführt wurde. Ich lag falsch. /etc/init.d/rsync start existiert im Hintergrund, wenn rsync in /etc/default/rsync nicht aktiviert ist . Dann müssen Sie es auch in /etc/rsyncd.conf konfigurieren , was ein Schmerz ist.
Wenn Sie das alles geschafft haben, müssen Sie rsync file.foo [email protected]::directory verwenden . Bitte beachten Sie, dass es zwei Doppelpunkte gibt .
Lösung 2:RSH-Server der alten Schule
Allerdings war mir die Konfiguration viel zu kompliziert. Also habe ich gerade installiert und rsh-server Auf meinem Laptop. Aufruf von rsync auf der Workstation mit -e rexec verwendet dann rsh anstelle von ssh. Was dann die Leistung auf 44,6 MB/s fast verdoppelte , was immer noch langsam ist. Die Geschwindigkeit schwankt zwischen 58 MB/s und 33 MB/s , was darauf hinweist, dass möglicherweise einige Puffer- oder Überlastungskontrollprobleme vorliegen. Aber das würde den Rahmen dieser Frage sprengen.
Lösung 4:
Dies sind sehr alte Fragen und Antworten, aber eine wichtige Sache fehlt:Wenn Sie bereits komprimierte oder verschlüsselte Daten kopieren, schalten Sie die Komprimierung aus.
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.
Wo ich gerade dabei bin, Sie können die X-Weiterleitung und die TTY-Zuweisung deaktivieren, was zu Folgendem führt:
rsync -avh -e "ssh -x -T -c arcfour -o Compression=no" $src $dst
Stellen Sie abschließend sicher (z. B. mit iptraf ), 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 das ausgehende ssh an die IP der standardmäßigen ausgehenden Schnittstelle gebunden war und nicht an die IP der Schnittstelle, auf der die Pakete weitergeleitet werden sollten. Mein direkter GB-Crossconnect zwischen zwei Laptops, die ebenfalls über WLAN verbunden waren, wurde nicht verwendet. Nach einer Untersuchung lag es daran, dass 169.254/16 verwendet wurde, das der Mac auf allen Schnittstellen installiert, und dass der Zielcomputer auf ARP-Anfragen geantwortet hat, obwohl die Anfrage auf einer anderen Schnittstelle einging.