Replication - warum so schnarchlangsam?

[Thomas_s-h]

Hallo,

ich versuche gerade einen Datenbestand zu "replizieren". Der liefernde Server ist ein Proliant N40L, derzeit um 60% CPU-Auslastung, Datenrate rund 70 MBit/s ( ca. 7 MByte/s). Der empfangende Server ist ein Proliant Gen8, der langweilt sich (CPU um 10%). Verschlüsselung ist aus, Komprimierung ist aus, die Leitung und die Server schaffen im direktem Kopierbetrieb 120 MByte/s. Die Datenrate im Replikationsdialog ist zuerst auf 0 (= unbegrenzt) eigestellt gewesen, aber auch eine Einstellung von 500 bringt nichts.

Warum ist das so langsam???

rsync hatte ich auch schon probiert, mit pull vom schnellerem Server, aber dann geht der puschende Server gleich auf 100% CPU-Last und es fliessen auch nur 100MBit/s. Außerdem hatte ich da div. Fehler (auf einmal wurden 3 TB an Daten gelöscht, ich weiss nicht warum, ist mehrfach passiert wenn ca. 95% der Daten übertragen waren).

Thomas

 

[Wishbringer]

rsync ist single threaded, Replication baut meines Wissens darauf auf.
Es wird somit nur ein Kern zu 100% ausgelastet, dies begrenzt somit dann auch die Kopierleistung.
(Push braucht mehr Power als Pull, ist somit meist der begrenzende Part).

In anderen Foren gab es mal Hinweise zu Scripts wie man durch mehrere parallel laufende rsync tasks ein Multithreading simulieren kann.
Ich habe die FreeNAS Entwickler schon zu 8.x Zeiten darauf aufmerksam gemacht.
Verbessert hat sich nichts.

Gerade zu Zeiten von stromsparenden CPUonMainboard Komponenten wie J1900, C2750, wo die einzelnen Kerne nicht unbedingt hohe IPS haben, aber dafür viele Kerne,
wäre eine solche Optimierung ein Schritt in Richtung Zukunftssicherheit.
(Bei 8 Kernen, einfach ein Script starten, welches immer darauf achtet, dass 8 rsync Tasks laufen, die Gesamtkopiermenge wird vorab in "Gesamtmenge/(Anzahl Kerne * zu ermittelnder Sicherheitsfaktor)" aufgeteilt und auf die Tasks verteilt.)

Lapidare Antwort: für rsync ist man nicht zuständig, ich möchte mich an dessen Programmierer wenden.

http://codereaper.com/blog/2014/the-dream-of-multi-threaded-rsync/

 

[Ericloewe]

Replication baut meines Wissens darauf [rsync] auf.

Stimmt nicht. ZFS replication funktioniert auf dem Niveau des Dateisystems, rsync arbeitet mit Dateien und Verzeichnisse.

 

[Wishbringer]

Meines Wissens nach gibt es zwei Methoden von Replication (nicht nur in ZFS):
Filebasiert (inkl. Metadaten) und blockbasiert.

Die Replication von ZFS ist nicht blockbasiert. Sonst müssten Quell- und ZielZFS strukturell (Größe, Aufbau) identisch sein.
Weiterhin würden Massen an ungenutzten Nullblöcken (bzw. deren komprimierte Pendants) übertragen werden.
Die Übertragung erfolgt daher Struktur- (Metadaten) und Filebasiert.

Der Vergleich mit rsync ist nicht bei den Haaren herbeigezogen:
ZFS-Replication arbeitet mit zfs send / zfs receive, welches starke Ähnlichkeit mit rsync push / rsync pull aufweist.

Aber zurück zum eigentlichen Grund:
Nämlich, dass Replication und rsync sehr langsam sind, wenn der sendende Part über eine geringe Rechenpower pro Kern verfügt.
Welche andere Ursache ausser dass das Vorbereiten der Daten zum Versenden, sowie dass die Koordination viel CPU-Power benötigen UND dass keine oder eine nicht optimale Multithreading-Unterstützung gibt, könnte es noch geben?!

 

[Ericloewe]

ZFS Replication muss keine Checksums rechnen, um zu wissen was noch nicht gesendet wurde. Rsync muss diese Checksums (auf beide Seiten) rechnen und braucht so viel mehr CPU Leistung als ZFS Replication.