Von Urs Pfister2 am Fr, 2. Dezember 2016 um 09:22 #
Soweit ich es beobachten kann, arbeitet nc im Grundsatz nicht schlecht, wenn auch der Aufruf nicht ganz so elegant ist.
Schneller ist nc aber nicht, weder bei NFS noch bei der DRBD-Variante. Bei 40 GBit-Karten z.B. hätte ich ca. 3 Minuten (DRBD-Variante) gegenüber ca. 5 Minuten bei netcat bei einer Datei von ca. 150 GByte. Verwendete Hardware:
Wenn alles glatt läuft, ist Kopieren von einer lokal gemounteten Offline-DRBD-Platte auf einen anderen lokalen Datenträger naturgemäß die beste Variante, da ja der Netzwerk-Overhead wegfällt. Meiner Erfahrung nach gibt es allerdings ein Problem, wenn beide Platten am selben Controller hängen. Da bricht recht schnell die Datenrate ein, sobald der Cache voll ist. Darauf war meine Aussage mit dem Bottleneck bezogen. In diesem Szenario geht es bei mir schneller mit netcat.
Das Praktische an netcat ist für mich, dass es sofort zur Hand ist und man nicht erst einen NFS-Server installieren und konfigurieren muss, um mal eben schnell ein Backup zu machen.
Optionen bezüglich Blockgrösse kenne ich keine, macht aber m.E. auch keinen Sinn, da sich nc rein aufs Pipen übers Netz beschränkt und den Rest den vorigen und nächsten Prozessen in der Pipe überlässt.
Dass nc+tar mehr CPU-Power benötigen als NFS+cp, wundert mich insofern, als dass im Fall von NFS ein Server involviert ist, der ja einen gewissen Overhead mitbringt. NFS läuft im Kernel - hast du dir in htop die Kernel-Threads eingeblendet bzw. in top auf die Angabe bei "sy" geachtet?
Von Urs Pfister2 am Fr, 2. Dezember 2016 um 20:23 #
Ich werde nochmals (aber frühestens nächste Woche) Tests mit 10 und 40 GBit fahren, und dabei nc gerne auch berücksichtigen, auch wenn ich heute eher das Gefühl hatte, nc wäre langsamer.
Und sicher ist nc recht praktisch, da überall verfügbar, auch wenn ich die Syntax jetzt nicht wahnsinnig berauschend finde. Zugegeben, dies NFS und DRDB konfiguriert sind, das dürfte länger dauern, in dieser Hinsicht ist nc dann gerade wieder einfach.
Bingo. nc ist übers Netzwerk immer am schnellsten. Auch bei 10GBit.
Tipp: sparse-Dateien effizient übertragen: 'tar cS'.
Das Bottleneck ist letztlich immer der Durchsatz dar langsamsten der beteiligten Komponenten.
Soweit ich es beobachten kann, arbeitet nc im Grundsatz nicht schlecht, wenn auch der Aufruf nicht ganz so elegant ist.
Schneller ist nc aber nicht, weder bei NFS noch bei der DRBD-Variante. Bei 40 GBit-Karten z.B. hätte ich ca. 3 Minuten (DRBD-Variante) gegenüber ca. 5 Minuten bei netcat bei einer Datei von ca. 150 GByte. Verwendete Hardware:
http://archivista.ch/cms/language/de/aktuell-blog/bigfoot-mit-40gbit
Nachfrage: Gibt es bei netcat Optionen, um die Blockgrösse festzulegen?
Sowohl bei nc als auch mit tar cS (auch kombiniert) benötige ich deutlich mehr CPU-Power als dies der Fall mit 'cp' und NFS/DRBD der Fall ist.
Wenn alles glatt läuft, ist Kopieren von einer lokal gemounteten Offline-DRBD-Platte auf einen anderen lokalen Datenträger naturgemäß die beste Variante, da ja der Netzwerk-Overhead wegfällt. Meiner Erfahrung nach gibt es allerdings ein Problem, wenn beide Platten am selben Controller hängen. Da bricht recht schnell die Datenrate ein, sobald der Cache voll ist. Darauf war meine Aussage mit dem Bottleneck bezogen. In diesem Szenario geht es bei mir schneller mit netcat.
Das Praktische an netcat ist für mich, dass es sofort zur Hand ist und man nicht erst einen NFS-Server installieren und konfigurieren muss, um mal eben schnell ein Backup zu machen.
Optionen bezüglich Blockgrösse kenne ich keine, macht aber m.E. auch keinen Sinn, da sich nc rein aufs Pipen übers Netz beschränkt und den Rest den vorigen und nächsten Prozessen in der Pipe überlässt.
Dass nc+tar mehr CPU-Power benötigen als NFS+cp, wundert mich insofern, als dass im Fall von NFS ein Server involviert ist, der ja einen gewissen Overhead mitbringt. NFS läuft im Kernel - hast du dir in htop die Kernel-Threads eingeblendet bzw. in top auf die Angabe bei "sy" geachtet?
Ich werde nochmals (aber frühestens nächste Woche) Tests mit 10 und 40 GBit fahren, und dabei nc gerne auch berücksichtigen, auch wenn ich heute eher das Gefühl hatte, nc wäre langsamer.
Und sicher ist nc recht praktisch, da überall verfügbar, auch wenn ich die Syntax jetzt nicht wahnsinnig berauschend finde. Zugegeben, dies NFS und DRDB konfiguriert sind, das dürfte länger dauern, in dieser Hinsicht ist nc dann gerade wieder einfach.