Re: Oeffentliche FTP-Server per rsync spiegeln?

Autor: Raphael Becker <rabe_at_shell.uugrn.org>
Datum: Mon, 2 Jul 2007 07:58:59 +0200
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


Empfangen am 02.07.2007

Dieses Archiv wurde generiert von hypermail 2.2.0 : 02.07.2007 CEST