Performance von `zfs send`

h^2

hat ne Keule +1
Ich mache regelmäßig Backups über das Internet mittels zfs send -R -I ... | ssh ... zfs recv -s -F -v.
Das funktioniert auch super. Aber es ist nicht sehr schnell; im Durchschnitt kriege ich so 3MB/s, möglich wären auf der Verbindung aber mehr als 10MB/s. Weder auf Sender noch auf Receiver sind die CPUs ausgelastet, also was ist hier der limitierende Faktor?
 
Im LAN ist zfs send/recv über ssh bei mir langsamer als ne Dateiübertragung per NFS oder iSCSI, aber nicht wesentlich.
So 70-80 MB/s statt 90 - 110.
Kannst du testweise eine große Datei über ssh/scp ans gleiche Ziel senden, zum Vergleich?
 
Ist ein VPN dazwischen? Es gibt noch den -c Schalter:
Generate a more compact stream by using compressed WRITE records for blocks which are compressed on disk and in memory (see the compression property for details). If the lz4_compress feature is active on the sending system, then the receiving system must have that feature enabled as well. If the large_blocks feature is enabled on the sending system but the -L option is not supplied in conjunction with -c, then the data will be decompressed before sending so it can be split into smaller block sizes. Streams sent with -c will not have their data recompressed on the receiver side using -o compress= value. The data will stay compressed as it was from the sender. The new compression property will be set for future data. Note that uncompressed data from the sender will still attempt to compress on the receiver, unless you specify -o compress= off.
 
Ich denke, dass es am Netzwerk liegt. Ich habe 2 Server, die jeweils einen "Spiegel" / Backup haben - und das Backup habe ich mit zfs send / zfs recv gemacht. Da wird immer die volle Brandbreite von 100 MB/sec ausgenutzt... Es sei den das (inkrementelle) Backup ist an einem Tag nur sehr klein...
 
Was liegt denn so "dazwischen"?

Ich hab zb immer mal wieder komische Sachen bei meinem privaten Anbieter gehabt da er Carrier-Grade-Nat macht, da war manchmal die ipv6 verbindung ohne selbiges stabiler, zb bei SSH verbindungen.

In diese Richtung (ipv4 vs v6, MTU, Packetfilter etc) würde ich evtl. mal schauen sofern das übers "öffentliche" Internet geht.
 
Und bedenkt, dass das SSH-Protokoll nie für Datenübertragungen gedacht war. Im LAN gehts meist noch, aber sobald höhere Latenzen ins Spiel kommen, macht es keinen Spaß mehr.
 
Danke für das Feedback!

Kannst du testweise eine große Datei über ssh/scp ans gleiche Ziel senden, zum Vergleich?
Also, wenn ich eine 1GB-Datei mit Zufallszahlen durch SSH ans Ziel `cat`e, dann kriege ich zumindest 7.8MB/s statt 3MB/s. Insofern ist SSH nicht das Hauptproblem, bzw. müsste auch mit SSH insgesamt mehr drin sein.
Es gibt noch den -c Schalter
Interessant, das gucke ich mir mal an. Ich bin immer davon ausgegangen, dass er komprimiert schickt, aber das ist ja dann wohl nicht default. Trotzdem müsste ich ja eigentlich mehr CPU-Load sehen wenn das der Bottleneck ist...
Da wird immer die volle Brandbreite von 100 MB/sec ausgenutzt...
Hm, das sugerriert ja, dass es nicht an ZFS liegt. Ich probiere mal etwas rum, wenn ich die Zeit finde.
 
ZFS per se wird da auch nicht das Problem sein, das rennt auf zu vielen Büchsen und wäre eher aufgefallen. Ein Flaschenhals wäre ein VPN (bisher nicht beantwortet :p), vor allem wenn nur eines der beiden Routerchen eher schwachbrüstig ist, kein AES-NI hat und dann selber nochmal komprimiert. Das gäbe nochmal Latenzen on top.

Trotzdem müsste ich ja eigentlich mehr CPU-Load sehen wenn das der Bottleneck ist...
WENN der bottleneck auf dem Router geschieht, siehst du ihn natürlich nicht auf der anderen Maschine. :)
Ich bin immer davon ausgegangen, dass er komprimiert schickt, aber das ist ja dann wohl nicht default.
Ist nicht default, da nicht unbedingt die gleichen Settings für Kompression beim Empfänger gewährleistet sind, die es ermöglichen wegzuschreiben, ohne dass die Blöcke erneut angefasst werden müssen. Die ähnliche 'Problematik' kommt auch bei nativ verschlüsselten datasets vor, wenn man nicht aufpasst. Wenn nämlich das entsperrte dataset geZFS-send-et wird und man --raw nicht setzt, wird unverschlüsselt zum Ziel übertragen. Guter, ausführlicher Artikel dazu: https://arstechnica.com/gadgets/2021/06/a-quick-start-guide-to-openzfs-native-encryption/

netcat eignet sich besser zum Übertragen, das muss selber auch keine Verschlüsselung können, dann aber entweder über VPN und wenn nicht, sendest du ein nativ verschlüsseltes dataset mit --raw rüber und bist auf der sicheren Seite. :)
Bonuspunkte für pv, damit sieht man dann auch, wie schnell es gerade schaufelt.
Anregung:
 
Ein Flaschenhals wäre ein VPN (bisher nicht beantwortet :p)
Kein VPN kommt zum Einsatz.

Die ähnliche 'Problematik' kommt auch bei nativ verschlüsselten datasets vor
Ja, das wird für mich auch irgendwann interessant. Momentan aber noch alles mit GELI.

Bonuspunkte für pv, damit sieht man dann auch, wie schnell es gerade schaufelt.
Jepp, das kommt eh zum Einsatz :)

Vielleicht hilft es, den Transfer durch mbuffer zu schicken?
Das sieht sehr interessant aus, das versuche ich auf jeden Fall beim nächsten Mal. Es scheint nämlich so, als ob die Übertragungsrate sehr stark schwankt. Vielleicht kriege ich damit eine dauerhaft höhere hin.
 
Es scheint nämlich so, als ob die Übertragungsrate sehr stark schwankt.
Das habe ich auch beobachtet, Schwankungen zwischen 10%-100%, egal ob im LAN oder via VPN durchs Internet. Mit Blick auf gstat und die Blinkintervalle der Platten-LEDs kam ich zum Schluß, dass der Sender drosselt, wenn das Ziel etwas länger zum Wegschreiben braucht. Im Schnitt landet es dann aber trotzdem beim nettomax, das die jeweilige Leitung im upload schafft.
Hast du mal die benötigte Zeit grob zur Datenmenge gegengerechnet? Nicht, dass man sich enttäuscht von den gerade angezeigten Werten ablenken lässt...
 
Ich sende immer durch mbuffer auf beiden Seiten, inspiriert von Dan Langille.
Damit bin ich bisher ganz gut gefahren und habe deutlich höhere Übertragungsgeschwindigkeiten als ohne.
 
Ich habe jetzt mal einen run mit mbuffer angeworfen.
Das Verhalten ist aber anders als erwartet. Ich hatte gedacht es läuft so:
  • Source kopiert Daten in den source-Buffer.
  • Wenn Source-Buffer voll (1GB), wird er durchs Internet geschickt
  • Sink-Buffer wird gefüllt
  • Wenn Sink-Buffer voll (1GB), wird er auf Platte des Ziel-Systems gedumpt

Das scheint aber nicht der Fall zu sein. Ich habe permanent reads auf dem Source-System und permanent writes auf dem Ziel-System. Die Ausgabe von mbuffer auf dem Ziel-System alterniert jede Sekunde zwischen 0% full und 100% full :confused:
 
Ich hatte gedacht es läuft so:
....
Generell sind ja Buffer vor allem dafür da, die Übertragungsgeschwindigkeit zu "glätten". Damit zum Beispiel die "Verschick-Routine" nicht auf die Platten warten muss, nur weil Du da gerade Lesekopfbewegung drin hast.
Insofern sind permantente Reads und permanente Write sogar völlig normal.

... alterniert jede Sekunde zwischen ...
Normalerweise hätte ich gesagt, der Buffer ist zu klein gewählt. Aber bei 1GB wird das wohl eher nicht die Ursache sein. Und man weiß ja auch nicht, wie verlässlich diese Ausgaben sind.
Die zentrale Frage ist eher: ändert sich was an der Übertragungsgeschwindigkeit?
 
Zurück
Oben