Performance von RSYNC

soul_rebel

ist immer auf der flucht
Ich mache hier regelmäßig Backups übers LAN mit rsync.
Leider ist das meistens ziemlich lahm. Komischerweise werden manche Dateien mit 6MB/s übertragen, während es meistens 800KB/s. Das alleine finde ich schon komisch...
Auf dem datenanbietenden Computer ist außerdem während eines Transfers die Auslastung bei ~85% (PC hat 670Mhz). 50% gehen auf das Konto von rsync und ca. 30% auf das Konto von sshd. Das erscheint mir recht seltsam, vor Beginn der Übertragungen und dazwischen berechnet rsync ja Prüfsummen für die Dateien, aber während eines Transfers :confused:
Auch frage ich mich wieso der sshd soviel schluckt, eine einfacher Download von demselben Server per sftp oder scp verursacht <5% Last. Das macht auch Sinn, denn die Verschlüsselung wird hardware-seitig gemacht....
Also wieso ist RSYNC so langsam und woher kommt die Prozessorbelastung?

Danke für Tipps!

edit: die Rsync parameter sind:
Code:
  rsync --verbose --archive --executability --times --progress --fuzzy \
  --human-readable --delete-after --one-file-system "$SRC" "$DEST"
 
Also ich kann meinen P4 mit 1.6 GHz mit über eine 100MBit Leitung per scp komplett auslasten. Insofern würde ich die Hardwareverschlüsselung als großen Erfolg werten.

Kann es sein, dass die Geschwindigkeit bei kleinen Dateien in den Keller geht?
 
Also ich kann meinen P4 mit 1.6 GHz mit über eine 100MBit Leitung per scp komplett auslasten. Insofern würde ich die Hardwareverschlüsselung als großen Erfolg werten.
Hm, na gut hab nur den scp-prozess bzw den sftp-prozesses betrachtet gerade (und nicht den zugehörigen sshd-prozess) :o
Die Last geht schon auf ca. 30%.... Aber die Verbindung ist dafür auch wesentlich besser ;)
Kann es sein, dass die Geschwindigkeit bei kleinen Dateien in den Keller geht?
Gerade nicht :S
Beim übertragen mehrer ca 700MB großer Dateien leigt die Geschwindigkeit meistens bei ca. 800KB/s, manchmal wesentlich höher. Bei der Ausgabe von rsync, kann man dann schön a sehen, dass er für die meisten dieser gleichgroßen Dateien mehr als 15 Minuten braucht, für andere nicht mal 2Minuten. Prozessorauslastung auf Seiten des Server scheint in beiden Fällen gleich zu sein (prüfe ich aber gleich nochmal, falls eine "schnelle Datei" mit dabei ist).
Kleine Dateien von ca. 5MB werden übrigens fast immer innerhalb von Sekunden übertragen...
 
Hallo,

sehr ähnliche Performance-Einbrüche habe ich auch schon mal bei rsync mit Linux als Ziel und Solaris als Quelle gesehen. Also scheint das Problem wahrscheinlich nicht die Ursache in FreeBSD zu haben.
Bisher dachte ich, dass es sich hierbei um ein Problem mit dem Software-RAID md(4) unter Linux (Centos 4.x) handelte.

Bei mir waren sehr viele Dateien mit Größen um 4 GB dabei bei einem Gesamtvolument von 200GB. Bei einer Hand voll brach die Transfergeschwindigkeit auf 800KB/s ein, obwohl die Dateien alle gleichartig waren (Oracle Tablespaces).

Ansonsten ist die Transfergeschwindigkeit bei ziemlich exakt genau 20 MB/s, was das Limit für die Kombination Intel 815 mit bge(4) zu sein scheint.

Würde mich auch interessieren, was die Ursache dafür ist.
 
Ich vermute du benutzt rsync um Daten abzugleichen? Wenn es sich bloß um ein Backup handelt, könntest du ja dump verwenden. Dass Dump nur ganze Dateisysteme dumpt kann man ja mit Nullfs-Mounts umgehen.
 
Hallo,

ein paar Informationen hat das Internet ausgespuckt:
1. der rsync-Server ist für Lese-Operationen optimiert und beherrscht Schreiben nur nebenbei. Hier ist der Vorschlag, dass man die Initiationssrichtung umkehrt, also den rsync-Befehl vom Ziel statt von der Quelle startet. Auf der Quelle muss dann der rsync-Dienst laufen

2. Die Option "-W" verhindert, dass er vor dem Kopieren eine Differenz errechnet, wenn er meint, dass es sinnvoll sein könnte, und nur die Differenz überträgt. Bei lokalen Netzwerken mit >= 100MBit sollte das volle Übertragen einer veränderten Datei schneller als das Berechnen einer Differenz sein. Unveränderte Dateien sollten wegen ihrem identischen Zeitstempeln trotzdem nicht übertragen werden.

@Kamikaze:
Für mein Problem funktioniert Dump nicht, Quell- und Ziel-Betriebssystem sich unterscheiden.
Dump liefert in den ersten Phasen, welche einige Minuten dauern kann, kaum Daten. Der Durchsatz später ist auch ziemlich gering (ein paar MB/s).
 
Back
Top