Frage Warum rsync ist schneller als NFS?


Vor ein paar Tagen habe ich etwas merkwürdiges bemerkt (zumindest für mich). Ich ransync kopiert die gleichen Daten und lösche sie anschließend auf NFS-Mount, aufgerufen /nfs_mount/TEST. Diese /nfs_mount/TEST wird gehostet / exportiert von nfs_server-eth1. Die MTU auf beiden Netzwerkschnittstellen ist 9000, der Switch dazwischen unterstützt auch Jumbo-Frames. Wenn ich mache rsync -av dir /nfs_mount/TEST/ Ich bekomme Netzwerkübertragungsgeschwindigkeit X MBps. Wenn ich mache rsync -av dir nfs_server-eth1:/nfs_mount/TEST/ Ich erhalte eine Netzwerkübertragungsgeschwindigkeit von mindestens 2 x MBps. Meine NFS-Mount-Optionen sind nfs rw,nodev,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountvers=3,mountproto=tcp.

Fazit: Beide Übertragungen gehen über das gleiche Netzwerk-Subnetz, dieselben Leitungen, dieselben Schnittstellen, lesen die gleichen Daten, schreiben in das gleiche Verzeichnis usw. Nur der eine Unterschied ist über NFSv3, der andere über rsync.

Der Client ist Ubuntu 10.04, der Server Ubuntu 9.10.

Warum ist rsync so viel schneller? Wie lässt sich NFS mit dieser Geschwindigkeit vergleichen?

Vielen Dank

Edit: Bitte beachten Sie, dass ich rsync verwende, um auf NFS-Freigabe oder SSH in den NFS-Server zu schreiben und dort lokal zu schreiben. Beides mache ich rsync -av, beginnend mit dem Zielverzeichnis. Morgen werde ich es mit einer einfachen Kopie versuchen.

Edit2 (zusätzliche Informationen): Dateigröße reicht von 1 KB bis 15 MB. Die Dateien sind bereits komprimiert, ich habe versucht, sie ohne Erfolg weiter zu komprimieren. ich machte tar.gz Datei von diesem dir. Hier ist das Muster:

  • rsync -av dir /nfs_mount/TEST/ = langsamste Übertragung;
  • rsync -av dir nfs_server-eth1:/nfs_mount/TEST/ = schnellste rsync mit aktivierten Jumbo Frames; ohne Jumbo-Frames ist ein bisschen langsamer, aber immer noch deutlich schneller als der direkt auf NFS;
  • rsync -av dir.tar.gz nfs_server-eth1:/nfs_mount/TEST/ = ungefähr das gleiche wie sein Nicht-tar.gz-Äquivalent;

Tests mit cp und scp:

  • cp -r dir /nfs_mount/TEST/ = etwas schneller als rsync -av dir /nfs_mount/TEST/ aber immer noch deutlich langsamer als rsync -av dir nfs_server-eth1:/nfs_mount/TEST/.
  • scp -r dir /nfs_mount/TEST/ = am schnellsten insgesamt, leicht überwunden rsync -av dir nfs_server-eth1:/nfs_mount/TEST/;
  • scp -r dir.tar.gz /nfs_mount/TEST/ = ungefähr das gleiche wie sein Nicht-tar.gz-Äquivalent;

Schlussfolgerung, basierend auf diesen Ergebnissen: Für diesen Test gibt es keinen signifikanten Unterschied, wenn Sie eine große Datei tar.gz oder viele kleine Dateien verwenden. Jumbo Frames on oder off macht auch fast keinen Unterschied. cp und scp sind schneller als ihre jeweiligen rsync -av Äquivalente. Das direkte Schreiben in die exportierte NFS-Freigabe ist wesentlich langsamer (mindestens zweimal) als das Schreiben in dasselbe Verzeichnis über SSH, unabhängig von der verwendeten Methode.

Unterschiede zwischen cp und rsync sind in diesem Fall nicht relevant. Ich beschloss es zu versuchen cp und scp nur um zu sehen, ob sie das gleiche Muster zeigen und sie tun - 2X Unterschied.

Wie ich es benutze rsync oder cp In beiden Fällen kann ich nicht verstehen, was verhindert, dass NFS die Übertragungsgeschwindigkeit der gleichen Befehle über SSH erreicht.

Wie kommt es, dass das Schreiben auf NFS-Freigabe 2 Mal langsamer ist als das Schreiben an dieselbe Stelle über SSH?

Edit3 (NFS Server / etc / exports Optionen): rw,no_root_squash,no_subtree_check,sync. Das / proc / mounts des Clients zeigt an: nfs rw,nodev,relatime,vers=3,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountvers=3,mountproto=tcp.

Danke euch allen!


33
2018-05-10 21:09


Ursprung


Sollte dies das gleiche Ergebnis für viele kleine Dateien und eine große Datei sein? - Xiè Jìléi
@notpeter - hat die Optionen im ursprünglichen Beitrag hinzugefügt. Vielen Dank! - grs
Ich weiß, dass dies eine ziemlich alte Frage ist, aber ein Hauptunterschied zwischen SCP und rsync, der einen kleinen Unterschied in der Übertragungszeit berücksichtigt, ist die automatische Dateitransfer-Prüfsumme, die ausgeführt wird, um zu zeigen, dass die Datei korrekt übertragen wurde. Dies unterscheidet sich von der Option -c von rsync, die eine Prüfsumme verwendet, um zu überprüfen, ob eine Datei zwischen Hosts aktualisiert wurde. Wenn Sie nur neue Dateien bearbeiten, die nicht ins Spiel kommen. - Rowan Hawkins


Antworten:


Vielleicht ist es nicht eine langsamere Übertragungsgeschwindigkeit, sondern eine erhöhte Schreiblatenz. Versuchen Sie, die NFS-Freigabe asynchron zu installieren, anstatt zu synchronisieren, und sehen Sie, ob dadurch die Geschwindigkeitslücke geschlossen wird. Wenn Sie rsync über ssh ausführen, schreibt der Remote-rsync-Prozess asynchron (schnell). Beim Schreiben in die synchron gemountete nfs-Freigabe werden die Schreibvorgänge jedoch nicht sofort bestätigt: Der NFS-Server wartet, bis er die Festplatte (oder eher den Controller-Cache) erreicht hat, bevor er dem NFS-Client eine Bestätigung sendet, dass der Schreibvorgang erfolgreich war.

Wenn 'async' Ihr Problem behebt, sollten Sie sich bewusst sein, dass, wenn etwas mit dem NFS-Server in der Mitte des Schreibvorgangs passiert, Sie sehr wahrscheinlich inkonsistente Daten auf der Festplatte erhalten. Solange dieses NFS-Mount nicht der primäre Speicher für diese (oder andere) Daten ist, werden Sie wahrscheinlich in Ordnung sein. Natürlich wären Sie im selben Boot, wenn Sie während oder nach dem Rsync-Over-Ssh den Stecker auf den NFS-Server gezogen haben (zB rsync kehrt mit 'Fertig' zurück, NFS-Server stürzt ab, nicht festgeschriebene Daten im Schreibcache sind nun verloren) inkonsistente Daten auf der Festplatte lassen).

Es ist zwar kein Problem mit dem Test (rsyncing new data), beachten Sie jedoch, dass rsync über ssh erhebliche CPU- und IO-Anforderungen auf dem Remote-Server stellen kann, bevor ein einzelnes Byte übertragen wird, während Prüfsummen berechnet und die Liste der Dateien generiert wird aktualisierte.


17
2018-05-12 04:02



Ich denke, diese Antwort ist die richtige. Wenn die Medien (Festplatten) auf den beiden Rechnern vergleichbar sind (gleiche RPM / Bandbreite / RAID-Konfiguration), können Sie durch umgekehrte Operation eine gute Vorstellung davon bekommen, ob dies der Fall ist: 'rsync -av / nfs_mount / TEST / dir 'Sonst wird die Synchronisierung ausgeschaltet und versucht, es zu testen. - Slartibartfast
Ich habe schnelle Tests mit sync vs async gemacht und ich denke, diese Antwort hat große Chancen, die richtige zu sein. Durch die Wahl von async wird die Lücke deutlich geschlossen, aber sie ist immer noch etwas langsamer als SSH. Ich werde weitere Tests machen und euch wissen lassen. Danke vielmals! - grs
Update: Meine neuen Tests zeigten einen signifikanten Unterschied in Bezug auf die Geschwindigkeit der Synchronisierung vs asynchronen NFS-Export-Option. Wenn NFS mit async und rsync -av dir.tar.gz /nfs_mount/TEST/Ich habe ungefähr die gleiche Übertragungsgeschwindigkeit wie mit rsync -av dir nfs_server-eth1:/nfs_mount/TEST/. Ich werde diese Antwort als richtig markieren, bin aber gespannt, ob ich das Setup weiter verbessern kann. Vielen Dank! Gut gemacht, bitte! - grs


NFS ist ein Freigabeprotokoll, während Rsync für Dateiübertragungen optimiert ist; Es gibt viele Optimierungen, die gemacht werden können, wenn Sie es wissen a priori Ihr Ziel ist es, Dateien so schnell wie möglich zu kopieren, anstatt gemeinsamen Zugriff darauf zu gewähren.

Dies sollte helfen: http://en.wikipedia.org/wiki/Rsync


18
2018-05-10 21:13



Wenn Sie die Daten vor der Hand kennen (was Sie normalerweise tun), können Sie die Komprimierung mit der Option selektiv ausschalten -e "ssh Compression=no" um möglicherweise eine schnellere Übertragungsgeschwindigkeit zu erhalten. Dadurch wird verhindert, dass Dateien komprimiert werden, die möglicherweise bereits komprimiert sind. Ich habe eine Geschwindigkeit sehr oft bemerkt. - lsd
Die @ lsd-ssh-Komprimierung ist standardmäßig deaktiviert und wird nicht für rsync empfohlen. Rsync erlauben, die Daten mit den Optionen zu komprimieren -z, --compress-level, und --skip-compress wird mit einem komprimierten Transport eine bessere Leistung erzielen. - JimB


Rsync ist ein Dateiprotokoll, das nur die geänderten Bits zwischen Dateien überträgt. NFS ist ein Remote-Verzeichnis-Datei-Protokoll, das jedes Mal alles behandelt ... irgendwie wie ein SMB in gewisser Weise. Die zwei sind verschieden und für verschiedene Zwecke. Sie können Rsync verwenden, um zwischen zwei NFS-Freigaben zu übertragen.


4
2018-05-10 22:08



Ich fühle mich ein bisschen schlecht, weil ich nichts gesagt habe, was technisch falsch ist, aber es scheint nicht so, als hätten Sie etwas zur Diskussion hinzugefügt, und Sie sind hereingekommen, nachdem viel spezifischere Informationen zur Verfügung gestellt wurden. Aus seinem Beitrag sieht es auch so aus, als ob der Autor sich dieser Dinge bewusst gewesen wäre. - Slartibartfast
Ich dachte, ich wäre der zweite Post und der Erste, der erwähnt, dass beide Protokolle mit unterschiedlichen Zielen waren. Es ist in Ordnung, ich dachte der erste Schnitt der Frage war ein bisschen dämlich. - pcunite


Das ist interessant. Eine Möglichkeit, die Sie möglicherweise nicht berücksichtigt haben, ist der Inhalt / Typ der Datei, die Sie übertragen.

Wenn Sie viele kleine Dateien (z. B. E-Mails in einzelnen Dateien) haben, kann die NFS-Effizienz tanken, weil Sie nicht die volle MTU verwenden (vielleicht ist dies jedoch weniger wahrscheinlich bei TCP als bei UDP).

Wenn Sie stark komprimierbare Dateien / Daten, schnelle CPUs und ein Netzwerk haben, das nicht die Geschwindigkeit der CPU (*) hat, können Sie die Beschleunigung nur durch implizite Komprimierung über die ssh-Verbindung erreichen.

Eine dritte Möglichkeit besteht darin, dass die Dateien (oder eine Version davon) bereits im Ziel existieren. In diesem Fall wäre die Beschleunigung, weil das Rsync-Protokoll speichert Sie die Übertragung der Dateien.

(*) In diesem Fall beziehe ich mich mit "Geschwindigkeit" auf die Rate, mit der die CPU Daten im Vergleich zu der Rate komprimieren kann, mit der das Netzwerk Daten übertragen kann, z. Es dauert 5 Sekunden, um 5 MB über die Leitung zu senden, aber die CPU kann diese 5 MB in 1 MB in 1 MB komprimieren. In diesem Fall beträgt die Übertragungszeit der komprimierten Daten etwas mehr als 1 Sekunde, während die unkomprimierten Daten 5 Sekunden betragen.


3
2018-05-11 03:46



Sehr gut! Die Dateien, mit denen ich versuche, sind viele kleine Bilder. Sie variieren in der Größe. Ich muss überprüfen, ob ich sie weiter komprimieren kann. Die Dateien existieren definitiv nicht am Ziel, da ich jedes Mal von vorne anfange. Morgen werde ich Tests mit einfachen machen cp -r vs rsync und dann werde ich die Dateien komprimieren, um größere Dateien zu haben, um von der MTU zu profitieren. Vielen Dank! - grs


Ich verwende auch -e "ssh Ciphers = arcfour", um den Durchsatz zu erhöhen.


1
2018-05-11 06:50



Braucht ein "-o". zB: "rsync -va -e" ssh -o Chiffren = arcfour "Quellziel: / Ziel /" - Pete Ashdown


Wenn Sie nur alle Dateien von einem Ort zum anderen kopieren möchten, ist tar / netcat die schnellste Option. Wenn Sie wissen, dass Sie viele Leerzeichen in Ihren Dateien haben (Nullen), verwenden Sie die Option -i.

QUELLE: tar cvif - / Pfad / zu / Quelle | nc DESTINATION PORTNUM ZIEL: cd / pfad / zu / source && nc -l PORTNUM | Teer xvif -

Wenn Sie wissen, dass Ihre Daten komprimierbar sind, verwenden Sie die Komprimierung für Ihre tar-Befehle -z -j -Ipixz

Ich bin ein Fan von pixz .. parallel xz, es bietet eine große Kompression und ich kann die Anzahl der CPUs, die ich habe, auf die Netzwerkbandbreite tunen. Wenn ich eine langsamere Bandbreite habe, verwende ich eine höhere Kompression, also warte ich auf CPU mehr als Netzwerk. Wenn ich ein schnelles Netzwerk habe, verwende ich eine sehr niedrige Komprimierung:

QUELLE: tar cvif - / Pfad / zu / Quelle | pixz -2 -p12 | nc DESTINATION PORTNUM # tar, ignoriere Nullen, Level 2 Pixz Kompression mit 12 CPU Kernen ZIEL: nc -l PORTNUM | tar -Ipixz -xvif

Wenn Sie die Komprimierungsstufe und die Kerne richtig einstellen, sollten Sie in Abhängigkeit von Ihrem Datensatz das Netzwerk nahe an Sättigung halten können und genug Komprimierung durchführen, damit der Engpass zur Festplatte wird (normalerweise die Schreibseite beim Lesen und Schreiben von Festplattensystemen) das Gleiche).

Wie für rsync glaube ich, es überspringt Nullen ähnlich der Art und Weise wie tar mit dieser Option, so dass es weniger Daten als NFS sendet. NFS kann keine Annahmen über die Daten treffen und muss daher jedes Byte zusammen mit dem NFS-Protokoll-Overhead übertragen. rsync hat etwas Overhead ..

netcat hat im Grunde keine. Es sendet vollständige TCP-Pakete, die nur Daten enthalten, die Ihnen wichtig sind.

Mit netcat, wie mit scp, müssen Sie alle Quelldaten die ganze Zeit senden, Sie können nicht wie bei rsync selektiv sein, also ist es nicht für inkrementelle Backups oder ähnliches geeignet, aber es ist gut zum Kopieren von Daten oder zum Archivieren.


1
2018-01-12 06:59





Haben Sie auf dem nfsshare Dateisperr-Setup? Sie könnten viel mehr Präformanz bekommen, wenn das deaktiviert wäre.


0
2018-05-11 04:42



Wie kann ich herausfinden, ob es aktiviert ist oder nicht? Das hier: docstore.mik.ua/orelly/networking_2ndEd/nfs/ch11_02.htm schlägt vor, dass NFS v3 keine Dateisperrungsfunktionen besitzt. - grs


Ich nehme an, dass die erhöhte Geschwindigkeit zumindest teilweise auf "rsync src host: / path" zurückzuführen ist, die einen lokalen Prozess auf dem Remote-Computer zum Senden / Empfangen hervorbringen, was effektiv Ihre E / A halbiert.


-1
2017-10-07 16:53