Re: grosser ftp server, disk i/o reduzieren?

From: Thomas <freebsdlists(at)bsdunix.ch>
Date: Wed, 01 Feb 2006 02:49:56 +0100

Hallo Olli

Oliver Fromme schrieb:
> Thomas <freebsdlists(at)bsdunix.ch> wrote:
> > Oliver Fromme:
> > > Bevor Du irgendwelche Maßnahmen ergreifst, die die Situa-
> > > tion möglicherweise »verschlimmbessern«, würde ich empfeh-
> > > len, harte Fakten zu sammeln und die I/O-Last zu messen.
> > > Zum Beispiel mit iostat(8) kann man feststellen, wieviel
> > > I/O gerade abgeht, und vmstat(8) kann man entnehmen, wie
> > > sehr das System durch Interrupts und I/O belastet wird.
> >
> > Das mach ich seit einigen Tagen. Interessant wird die Lastverteilung
> > während dem Opensuse 10.1 Final Release zu messen. Da ist
> > erfahrungsgemäss der Server ca. 200 FTP User, einige Rsync Prozessen am
> > Limit.
>
> Hm, also auch rsync (zuerst war ja nur von FTP die Rede).
> Ich weiß nicht, ob sich da in jüngster Zeit etwas verbes-
> sert hat, aber früher war rsync immer ein großer Speicher-
> fresser. Da würde ich mir mehr Sorgen drüber machen als
> über FTP.

Ja rsync frisst Speicher. Die Rsync Prozesse brauchen wir um Daten von
diversen Mirrors zu hollen. D.h. wir haben direkten Einfluss auf den
Start der Rsync Prozesse. Diese werden vorwiegend Nachts gestartet, wenn
die Anzahl der verbundenen ftp User um ca. 30-40% niedriger ist als den
Tag durch.
Wir bieten rsync fuer User an. Dieser Dienst wird jedoch kaum in
Anspruch genommen und faellt deshalb den Tag durch kaum ins Gewicht.

> Nochmal zum Thema RAM-Vergrößerung: Falls Du diese allein
> deswegen machen willst, um mehr Daten des FTP-Servers zu
> cachen, dann fürchte ich, daß das wenig bis gar nichts
> bringen wird. Warum? Nun, angenommen, es sind (nach dem
> Update) 2 Gbyte frei für den Bugffer-Cache (das dürfte
> ungefähr realistisch sein). Dann bringt es Dir genau dann
> etwas, wenn die Dateien, die am häufigsten herunetrgeladen
> werden, zusammengenommen nicht größer als 2 Gbyte sind,
> denn anderenfalls läuft der Cache ständig in einen soge-
> nannten Trashing-Effekt hinein, wo sich die Daten ständig
> gegenseitig aus dem Cache verdrängen und dann doch wieder
> von der Festplatte geladen werden müssen. Und 2 Gbyte ist
> nicht viel; das entspricht etwa drei CD-ISO-Images.

Interessant. Würde hier noch mehr Ram helfen?
Fakt ist, dass die User meist nur immer die neusten ISOs downloaden.
D.h. bringt Fedora ein neues Release macht dieses am meisten Traffic,
wenn Suse was released dann werden diese ISOs heruntergeladen. Da diese
alle nicht zur selben Zeit neue Releases praesentieren verteilt sich das
alles immer schoen übers Jahr-

Interessant waere natuerlich, wenn man Einfluss nehmen koennte, was im
Buffer sein muss.

>
> Falls Du dagegen den RAM vergrößern mußt, damit alle ftpd-
> und rsync-Prozesse hineinpassen und nicht gepaged oder
> geswappt werden müssen -- dann ist das natürlich ein sehr
> guter Grund.

Die Kiste swaped eigentlich so gut wie nie auch nicht unter Last mit den
2GB Memory.

> > gstat hab ich auch am laufen. Ist öfters im roten (100+) Bereich auf den
> > Platten mit dem Adaptec Sata 2810SA Controller.
>
> Ohne das selbst näher zu untersuchen, kann ich natürlich
> auch nur spekulieren. Folgendes ist eine Vermutung (oder
> sagen wir mal Hypothese).
>
> Da das Caching im RAM wohl nicht sehr effektiv ist (s.o.),
> gehen die Downloads -- oder zumindest Teile davon -- direkt
> auf die Festplatten. Wenn gleichzeitig viele unterschied-
> liche Dateien heruntergeladen werden, führt das zu einer
> großen Zahl von Seek-Operationen der Festplatten (d.h. Be-
> wegungen der Köpfe). Diese kosten Performance.
>
> Um das Problem zu mildern, würde es sich vermutlich lohnen,
> die Anzahl der Festplatte zu vergrößern, und/oder die
> beliebten Download-Bereiche geschickter über die Fest-
> platten zu verteilen. Die beiden beliebtesten Bereiche
> sollten nicht auf derselben physikalischen Festplatte sein.

Ja. Das ist sicherlich eine gute Moeglichkeit. Macht es aber etwas
schwierig zu Maintainen. Erstens brauchen die grossen Projekte alle
allein jeweils etwas mehr als 250GB an Plattenplatz. Momentan haben wir
nur jeweils 250GB Platten in Betrieb. D.h. aktuell könnte ich keines der
grosse Mirror Projekte auf eine separate Disk verlagern.

> (Das ist auch ein Grund, warum RAID-5 bei solchen Anwen-
> dungen eher kontrapropduktiv ist: Man hat wenig Kontrolle
> darüber, welche Dateien auf welchen Festplatten landen.)

Das stimmt schon. Was ist die alternative? Ein Raid0? Das bringt mir
mehr speed, dafuer sind die Daten bei einem Ausfall einer Platte futsch.
Das ist zumindest meine Erfahrung. Lass mich gerne von etwas anderem
Ueberzeugen.

> > Ausserdem fällt ca. alle 12 Monaten eine Sata Platte aus. Bei einem
> > Ausfall ohne Raid müssten wir zuerst alle 2 Terra Daten wieder komplett
> > neu downloaden.
>
> Nein -- nur die Daten, die auf der ausgefallenen Platte
> waren. Ich nehme nicht an, daß Ihr 2Tb große Festplatten
> verwendet. :-) Und während der FTP-Mirror wieder syn-
> chron gemacht wird, kann der Rest des Servers ja weiter-
> laufen, d.h. der Ausfall betrifft nur einen Teil des
> Servers.

Sorry, ich meinte natuerlich ein Disk stripping. In
diesem Fall musste man alles neu downloaden.

>
> Davon abgesehen könnte man theoretisch auch alles auf
> einen zweiten, gleichgroßen Plattenstapel backuppen.
> Allerdings kostet das natürlich deutlich mehr als ein
> RAID-5, daher ja auch nur »theoretisch«.

Das wird schwierig. Das Gehause bietet Platz fuer 16 Disks. Wir haben
heute entschieden das System auszubauen und somit wirds kaum Platz haben
fuer einen zweiten Plattenstapel.
Immerhin bekomme ich die Gelegenheit einen Aretac Controller direkt mit
dem Adaptec Controller zu vergleichen.

Einen weiteren Rechner für das "Backupen" ist keine Alternative. Man
muss sehen, dass ein Mirror aus finanzieller Sicht absoluter Humbug ist.
Hardware kostet Geld, Traffic kostet Geld, Strom kostet Geld und durch
den Mirror gewinnen wir nicht mehr Kunden. Deshalb ist es immer das Ziel
das Optimum aus einem Rechner zu holen.

Gruss
Thomas

> Gruß
> Olli
>
> PS: Das SI-Prefix heißt »Tera«, mit einem r (und meistens
> mit langem e gesprochen). Es leitet sich aus dem Griechi-
> schen ab (ob von »teras« oder »tetra«, ist nicht ganz unum-
> stritten, aber ersteres ist die verbreitetstere Ansicht).
> »Terra« ist in diesem Kontext ebenso weitverbreitet wie
> falsch -- es ist lediglich das lateinische Wort für Erde.
> Es hat absolut nichts mit dem Einheiten-Prefix zu tun.

Danke :)

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Wed 01 Feb 2006 - 02:53:54 CET

search this site