☰

Rsync-Übertragung über SSH ist sehr langsam

tag-icon • tag-icon backup rsync
Rsync-Übertragung über SSH ist sehr langsam

Ich erstelle ein Remote-Backup meiner Website. Der gesamte Katalog ist etwa 70 GB groß und enthält insgesamt etwa 5.000.000 Dateien. Hier ist der Befehl, den ich auf meinem Backup-Server ausführe:

rsync -ah -e ssh --delete --link-dest=/backups/2013.09.06 [email protected]:/var/www/backups/2013.09.07

Der Vorgang läuft länger als 48 Stunden und bleibt dann einfach hängen.

Ich habe strace -pden Rsync-Prozess auf dem Client (dem Webserver, auf dem sich die Website befindet) ausgeführt und gesehen, dass der Prozess regelmäßig bei Befehlen, die nach einiger Zeit selectenden , anhält und dann fortgesetzt wird.= 0 (Timeout)

open("mysite/files/1694201", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=10083, ...}) = 0
read(3, "\r\n\320\224\320\265\321\201\321\217\321\202\321\214 \320\273\320\265\321\202, \321\210\320\265\321\201\321\202\321"..., 10083) = 10083
select(2, NULL, [1], [1], {60, 0})      = 1 (out [1], left {59, 999998})
write(1, "\374\17\0\7", 4)              = 4
select(2, NULL, [1], [1], {60, 0})      = 1 (out [1], left {59, 999999})
write(1, "\320\260\320\262\320\260\320\271\321\202\320\265...\320\232\320\270\320\264\320\260\320\271\321\202\320\265 \320\274"..., 4092) = 4092
select(2, NULL, [1], [1], {60, 0})      = 1 (out [1], left {59, 999999})
write(1, "\374\17\0\7", 4)              = 4
select(2, NULL, [1], [1], {60, 0})      = 0 (Timeout)

Der Vorgang bleibt etwa eine Minute lang in der letzten Zeile hängen.

Warum kann das passieren? Warum dauert der Prozess so lange und kommt nie zum Abschluss? Was könnten die Betroffenen 0 (Timeout)damit meinen?

Auf beiden Servern läuft rsync 3.0.9, die IO ist nicht überlastet.

Antwort1

Was könnte diese 0 (Timeout) in strace bedeuten?

Informieren Sie sich über den 5. Parameterübergeben an select.

Offensichtlich ist rsync (allein) nicht für die Methode geeignet, die Sie zum Sichern der Dateien gewählt haben. Es muss für jede der 5 Millionen Dateien einen Hash generieren und diesen über das Netzwerk senden, nur um festzustellen, ob sich etwas geändert hat.

Wenn ich es wäre, würde ich es in ein Skript einbinden, das auf dem Quellserver ausgeführt wird und

  1. Überprüft die Zeit (tstart), zu der die vorherige erfolgreiche Synchronisierung gestartet wurde

  2. Findet alle Dateien in der Quelle, deren mtime > tstart ist.

  3. rsync die geänderten Dateien auf den Backup-Server

z.B

#!/bin/bash

touch newrun
find /var/www -newer lastrun -exec rsync ....
rm -f lastrun
mv newrun lastrun

Antwort2

sind Sie sicher, dass Sie 5 Milliarden Dateien haben?

Ich würde lieber tgz und rsync als tgz verwenden, da der erste Vergleich von src zu dst ewig dauern würde, wenn Sie einigermaßen „normale“ Festplatten und kein Hochgeschwindigkeits-SAN oder SSD haben.

Wo ist Ihr Prozess langsam? Während der Dateiübertragung oder während der anfänglichen Quelle-Ziel-Prüfung? (Senden einer inkrementellen Dateiliste ...)

Ich würde, wenn möglich, IOWAIT an beiden Enden überprüfen. Und wenn die Maschinen über MD-RAID verfügen, cat /proc/mdstatus. Eine sehr schlechte E/A-Leistung kann das Ergebnis eines neu aufgebauten RAIDs sein (ist aber sehr unwahrscheinlich).

und ich würde eine Übertragung mit einer einzelnen großen Datei durchführen, wobei --progresswährend der Rsync-Übertragung eingeschaltet sein muss, um die Netzwerkgeschwindigkeit zu prüfen.

Hinweise zur Fehlerbehebung(Sie sollten jeden möglichen Engpass testen, auch nur um sicherzugehen, dass dies NICHT das Problem ist)

  • Versuchen Sie rsync mit -avzh --progress --stats
  • io-performance lokal
  • Netzwerkleistung
  • hd/raid-status (SMART), auf fehlerhafte Hardware prüfen

verwandte Informationen