Mich würde mal der Vergleich mit NetCat und das mit und ohne Kombination mit PipeViewer interessieren. Das nutze ich nämlich ab und an ganz gerne mal.
In der Vergangenheit hat sich die Kombination auch für viele kleine Dateien als sehr performant erwiesen. Als Beispiel:
PC1: tar c . | pv -s [größe] | nc -l -p 2002 PC2: nc [PC1] 2002 | tar x
Bisher konnte ich damit bessere Ergebnisse erzielen als mit SCP, NFS +co.
Da ich aber bisher nicht über Gigabit Ethernet hinaus gekommen bin und es sich zumeist auch um Rotationsplatten handelte... ich mein, es könnte ja bei 10G und SSD anders aussehen...
Insbesondere weiß ich nicht, in wie weit die involvierten Programme effiziente Pipes unterstützen. Wenn alle Daten zwischen den Prozessen im Speicher hin und her kopiert werden müssen, dann wird das mit 10G schon recht rechenintensiv.
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.
Mich würde mal der Vergleich mit NetCat und das mit und ohne Kombination mit PipeViewer interessieren. Das nutze ich nämlich ab und an ganz gerne mal.
In der Vergangenheit hat sich die Kombination auch für viele kleine Dateien als sehr performant erwiesen. Als Beispiel:
Bisher konnte ich damit bessere Ergebnisse erzielen als mit SCP, NFS +co.
Da ich aber bisher nicht über Gigabit Ethernet hinaus gekommen bin und es sich zumeist auch um Rotationsplatten handelte... ich mein, es könnte ja bei 10G und SSD anders aussehen...
Insbesondere weiß ich nicht, in wie weit die involvierten Programme effiziente Pipes unterstützen. Wenn alle Daten zwischen den Prozessen im Speicher hin und her kopiert werden müssen, dann wird das mit 10G schon recht rechenintensiv.
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.
Je nach CPU- und Netzwerkgeschwindigkeit könnte es sich noch lohnen, mit einem schnellen Kompressor wie z.B. lzop zu arbeiten.