Re: Oeffentliche FTP-Server per rsync spiegeln?

[Raphael Becker <rabe@xxxxxxxxxxxxxxx>]

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 verfuegbarem 
> 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 naemlich wieder von Platte gelesen werden und 
> das kostet Performance.
> 
> Also waere meine Schlussfolgerung dass es auf die Daten und den verfuegbaren 
> Hauptspeicher ankommt ob man rsync oder ftp/http einsetzen sollte. Wenn z.B. 
> ein Datenbestand mit wenigen Dateien haeufig ausgeliefert wird, dann waere wohl 
> rsync das Mittel der Wahl. Werden jedoch grosse Datenbestaende mit vielen 
> Dateien ausgeliefert und der Cache kann es nicht halten, dann waere wohl eher 
> ftp/http gefragt.

Beispiel: ich syncronisiere derzeit taeglich top.uugrn.org mit allen
Filesystemen auf den kleinen LAN-Bruder (bottom.uugrn.org), der zu 
diesem Zweck voruebergehend bei mir daheim online ist.

root@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 benoetigt gut 3min allein um einmal durch alle Verzeichnisse zu
schiessen, um alle rund 1,3 Millionen Dateien und Verzeichnisse
aufzulisten. Das System verfuegt ueber 512MB RAM und eine einfache
SATA-Platte.

Den weitaus ueberwiegenden Anteil wartet er dabei auf die Festplatte,
lediglich knapp 13sec CPU-Zeit wird benoetigt.

Rsync benoetigt fuer den gesamten Mirror real-time 18min und hat dabei
heute morgen in der Summe 170MB empfangen und 3.1MB gesendet (alle
geaenderten Dateien der letzten 24h plus Steuerinformation fuer 1.3Mill
Dateien, insgesamt 41860MB). 

Ich moechte 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 fuer
wenige Dateien sinnvoll ist. 

> Hier geht es ja hauptsaechlich um die Vorbereitung der Datenuebertragung. Ich 
> denke wir sind uns einig dass die eigentliche Datenuebertragung mit rsync, ftp 
> und http ungefaehr gleich schnell sein wird.

AFAIK wird ein aehnlicher Prozess auf beiden Enden gestartet und laeuft
dort jeweils ohne Steuerbefehle uebers Netz, d.h. autonom. Es wird
lediglich die Ergebnisliste gepackt uebertragen. Der anfragende Host
vergleicht dann beide Listen und generiert daraus eine todo-Liste fuer
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.

--------------
Fuer den angefragten Host ("Master") ist es demnach egal, denn er muss in
jedem Fall den gesamten (angefragten) Datenbestand traversieren und 
uebertraegt Verzeichnislisten im ein oder anderen Format.
--------------

Wie an anderer Stelle von naddy schon angedeutet: Wenn es nur
kontrollierte (bekannte, protokollierte) Aenderungen auf dem Master gibt,
kann der Client (Mirror) gezielt die Aenderungen nachvollziehen und ggf.
deltas uebertragen. 

rsync haette IMHO in Verbindung mit Filesystem-snapshots (definierte 
Zustaende!) u.U. das Potenzial, sowas (zukuenftig) zu leisten, alles 
was "pollt" erzeugt auf die ein oder andere Art unnoetigen Overhead, 
egal ob (aktuelles) rsync, ftp oder http.

Gruss
Raphael



-- 
http://mailman.uugrn.org/mailman/listinfo/uugrn