Hi Markus, hallo Liste, On Sun, Jul 01, 2007 at 01:03:29PM +0200, Markus Hochholdinger wrote: > Jetzt habe ich festgestellt, dass je nach Anzahl der Dateien und verfügbarem > Hauptspeicher auf dem Quell-System die ganze Performance zusammenbricht, wenn > der Cache nicht alles halten kann. Bei mir ist das passiert bei ca. 100000 > Dateien und 2GB RAM. Dann muss nämlich wieder von Platte gelesen werden und > das kostet Performance. > > Also wäre meine Schlußfolgerung dass es auf die Daten und den verfügbaren > Hauptspeicher ankommt ob man rsync oder ftp/http einsetzen sollte. Wenn z.B. > ein Datenbestand mit wenigen Dateien häufig ausgeliefert wird, dann wäre wohl > rsync das Mittel der Wahl. Werden jedoch große Datenbestände mit vielen > Dateien ausgeliefert und der Cache kann es nicht halten, dann wäre wohl eher > ftp/http gefragt. Beispiel: ich syncronisiere derzeit täglich top.uugrn.org mit allen Filesystemen auf den kleinen LAN-Bruder (bottom.uugrn.org), der zu diesem Zweck vorübergehend bei mir daheim online ist. root_at_bottom:~# time find /data/top.uugrn.org/ | wc -l 1314965 real 2m58.122s (~2m28s bei allen folgenden Aufrufen) user 0m2.861s sys 0m9.769s Er benötigt gut 3min allein um einmal durch alle Verzeichnisse zu schießen, um alle rund 1,3 Millionen Dateien und Verzeichnisse aufzulisten. Das System verfügt über 512MB RAM und eine einfache SATA-Platte. Den weitaus überwiegenden Anteil wartet er dabei auf die Festplatte, lediglich knapp 13sec CPU-Zeit wird benötigt. Rsync benötigt für den gesamten Mirror real-time 18min und hat dabei heute morgen in der Summe 170MB empfangen und 3.1MB gesendet (alle geänderten Dateien der letzten 24h plus Steuerinformation für 1.3Mill Dateien, insgesamt 41860MB). Ich möchte behaupten, dass das Traversieren durch VIELE Verzeichnisse mit VIELEN Dateien per FTP oder HTTP deutlich mehr Overhead generiert (abseits vom Dateitransfer selbst) und FTP/HTTP-Mirror daher eher für wenige Dateien sinnvoll ist. > Hier geht es ja hauptsächlich um die Vorbereitung der Datenübertragung. Ich > denke wir sind uns einig dass die eigentliche Datenübertragung mit rsync, ftp > und http ungefähr gleich schnell sein wird. AFAIK wird ein ähnlicher Prozess auf beiden Enden gestartet und läuft dort jeweils ohne Steuerbefehle übers Netz, d.h. autonom. Es wird lediglich die Ergebnisliste gepackt übertragen. Der anfragende Host vergleicht dann beide Listen und generiert daraus eine todo-Liste für den Remote-Host. Mal ganz grob. Bei FTP/HTTP steuert der anfragende Host den Remote-Host durch alle Verzeichnisse (die ihn interessieren). D.h. der Remote-Host muss so oder so, mindestens den eigenen Datenbestand durchlaufen. Bei rsync tut er es aber nach eigenem Ermessen und Performance. -------------- Für den angefragten Host ("Master") ist es demnach egal, denn er muss in jedem Fall den gesamten (angefragten) Datenbestand traversieren und überträgt Verzeichnislisten im ein oder anderen Format. -------------- Wie an anderer Stelle von naddy schon angedeutet: Wenn es nur kontrollierte (bekannte, protokollierte) Änderungen auf dem Master gibt, kann der Client (Mirror) gezielt die Änderungen nachvollziehen und ggf. deltas übertragen. rsync hätte IMHO in Verbindung mit Filesystem-snapshots (definierte Zustände!) u.U. das Potenzial, sowas (zukünftig) zu leisten, alles was "pollt" erzeugt auf die ein oder andere Art unnötigen Overhead, egal ob (aktuelles) rsync, ftp oder http. Gruß Raphael -- http://mailman.uugrn.org/mailman/listinfo/uugrn
Dieses Archiv wurde generiert von hypermail 2.2.0 : 02.07.2007 CEST