rsync bandbreite bricht ein

P

peter0406

New Member
ich will von meinem Notebook (Linux OpenSuse Leap 15.5) auf unseren Linux Server (OpenSuse Leap 15.5) mein /home Laufwerk sichern.

Der Linux-Server exportiert die Platte über nfs mit

Code: 
/run/media/peter/Daten  *(rw,no_root_squash,sync,no_subtree_check)


mit folgendem Kommando will ich mein Homelaufwerk sichern

Code: 
rsync -avPHAXx --delete --exclude-from=exclude_home /home/peter/ peter@linux-server:/run/media/peter/Daten/home_peter


Zu Beginn kopiert rsync mit ca. 30 GByte / s. Der Server ist mit einem 1 GBit/s LAN angebunden.
Nach kurzer Zeit bricht die Datenrate auf ca. 30 KByte/s ein (um den Faktor 1000 !).
Ich finde keinen Grund für den Einbrauch der Datenrate.
Ich habe auch schon mit der Option -e "ssh -T -c arcfour -o Compression=no" versucht. Aber an der Verschlüsselung scheint es nicht zu liegen
 
Die vermeintlichen (und völlig unrealistischen) 30 GB/s kommen daher, dass die Daten zuerst in einen Ram-Cache kopiert und dann von da sukzessive auf den Zieldatenträger geschrieben werden. Realistisch bei 1 GBit LAN sind max. so um die 100 MB/s. Das glättet sich dann mit der Zeit und nähert sich einem realen Wert an.
Dass es danach so massiv einbricht kann an sehr vielen kleinen Dateien liegen. Wieviele Dateien sollen denn da kopiert werden?
Ich habe mal den Fehler gemacht mein Home Verzeichnis aufs NAS zu kopieren, dabei aber einen Anaconda Ordner (Python Library Sammlung) mit einzuschließen. Da lief die Kopierung auch nur mit 30 kB/s weil da tausende Dateien drin sind die nur wenige kB groß sind. Dasselbe passiert z.B. auch bei großen git/SVN Repos.
Wenn man aber nur wenige aber sehr große Dateien kopiert sind die 100MB/s durchaus realistisch.
 
wakko said:
Ich habe mal den Fehler gemacht mein Home Verzeichnis aufs NAS zu kopieren, dabei aber einen Anaconda Ordner (Python Library Sammlung) mit einzuschließen. Da lief die Kopierung auch nur mit 30 kB/s weil da tausende Dateien drin sind die nur wenige kB groß sind. Dasselbe passiert z.B. auch bei großen git/SVN Repos.
Click to expand...
Viele kleine Files packt man dann sinnvollerweise in ein Tarball und sichert das dann. ;)
 
Oder man schließt solche Ordner von vornherein aus der Sicherung aus. Lektion gelernt, seitdem habe ich eine exclude Liste.
 
Wenn Du den rsync das erste Mal durchgeführt hast, wie lange braucht denn der darauf folgende rsync-Vorgang? (Tip: "time rsync ...")

Ich würde ja sagen, dass das recht wurscht ist, ob das jetzt 1 Minute oder 15 braucht. Nur ab 1 Stunde aufwärts fände ich das recht nervig. Auf meinem Arbeitsplatzcomputer dauert eine Sicherung bei ca. 800.000 Dateien zwischen 1 und 25 Minuten (rsync via Internet). Erster Sync: 4 Stunden - da war der Flaschenhals die Internetverbindung.
 
Last edited:
Sorry, die 30 GByte / s sind ein Druckfehler. Es fängt mit 30 MByte / s an.
Ich habe mittlerweile durch weitere Analysen erkannt, dass das Problem die Quelle ist.
Kleinere Dateien gehen recht flott. Wenn dann die erste größere Datei kommt (> 500 MByte) beginnt auch hier die Übertragung mit der genannten Bandbreite von 30 MByte / s. Nach wenigen Minuten bricht die Bandbreite aber auf 30 KByte / s ein (um den Faktor 1000). Die CPU auf dem Ziel ist idle, das Netz ist idle. Alleine der Quellprozess schafft nur noch wenige KByte/s. Der Linux-Prozess schläft meistens (ist aber nicht tot). Ab und zu wacht er auf und überträgt ein paar Byte. Wie kann ich ermitteln, was diesen Prozess so stark ausstoppt ?
 
Da könntest Du z. B. systematisch rangehen:
  • Die eingestellte Geschwindigkeit Deiner Netzwerkkarten prüfen (ethtool / mii-tool)
  • Mit IPerf Deine Netzwerkgeschwindigkeit in beide Richtungen (!) testen. Vielleicht ist auf physikalischer Ebene (Verkabelung/Switch) ein Problem.
  • Die Festplatte / SSD testen, ob die dauerhaft gute Performance bringt. (Was altes / einfaches wäre bonnie++ oder mit einem dd mal ein paar GB lesen und schreiben.). Auch das Smartlog Deiner Festplatten/SSDs prüfen (smartctl)
  • Die lokalen und entfernten Systemleistungsdaten während des Vorgangs messen (z. B. mit dstat) und beobachten.
  • Das Debuglevel von rsync hochstellen und schauen, ob da irgend etwas seltsames an Fehlermeldungen kommt.
  • Die Systemprotokolle (/var/log/{messages,syslog,kern.log} bzw. journctl) und dmesg von beiden Hosts nach möglichen Fehlern und Warnungen durchsuchen
 
Last edited:
Du könntest auch versuchen, das rsync mal "ziehend" vom Zielsystem aus laufen zu lassen.
Ich hatte vor 2 Monaten das Phänomen beim Komplettumzug eines Servers auf ein neues System. Hatte zuerst vom Quellsystem (alter Server) mit rsync Daten auf den neuen Server "geschoben". Das hatte dasselbe Problem wie bei Dir. nach wenigen Minuten ist die Datenrate eingebrochen. Als ich dann rsync auf dem Zielsystem als "ziehend" habe laufen lassen ging es durchgehend schnell. Habe leider nie rausgefunden woran das lag.
 
ich habe es in der Tat mal ziehend probiert. Aber der gleiche Effekt. Am Anfang zügig mit ca. 30..40 Mbyte /s. Dann bricht es plötzlich ein auf 20..30 KByte/s. Und diesmal waren es tausende von kleinen Dateien, keine großen. Bricht zwar nicht ganz ab, wird aber auch nicht wieder schneller. Und auf beiden Rechnern verschwinden die Prozesse aus der htop Übersicht und tauchen nur noch sporadisch auf.

Die oben angegebenen Tipps habe ich fasst alle durch. iperf3 vom client und server bestätigt eine Datenrate von ca. 900 MBits/s .

Die Platten in Quelle und Ziel haben keine Probleme. PASSED, nichts in den ERROR_RATES, completed without error. Nichts auffälliges in ethtool. Die Festplatte Quelle und Ziel habe ich durch lokale rsync getestet. Lokal erreichen sie bei rsync auch mal 100 MByte/s
wie stelle ich das Debug level von rsync hoch ? ich kenne nur -vP --stats --progress
wie bediene ich dstat ?
 
wenn man den laufenden rsync job abbricht und wieder neu startet, fängt er bei der gleichen Datei wieder an (wo er abgebrochen wurde) aber nun mit der 10 fachen Geschwindigkeit. Das ist daher m. A. n. kein Problem der Datei oder der Platte, es hat irgendwie mit dem Prozess und dessen Resourcen zu tun (Buffer voll oder ähnliches). Aber der Zeitraum bis die Bandbreite einbricht ist auch nicht immer gleich (wobei ich natürlich nicht die übertragenen Bytes zählen kann). Dabei sind pull oder push egal. Beide Richtungen betroffen
 
Last edited:
das Problem ist gelöst. Sauerland hatte den richtigen Tipp. Ich habe auf dem zu sichernden Client mit ipv6.disable=1 als optionalem Bootparameter ipv6 abgeschaltet. Ich habe Übertraungsraten vopn fast 100 MByte/s gesehen - fast das Maximum für 1 GBit/s Netze. Danke für die Hilfe
 
Last edited:
You must log in or register to reply here.
Back
Top