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

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.

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.

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.

> 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.

(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.)

> 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.

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«.

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.

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"What is this talk of 'release'?  We do not make software 'releases'.
Our software 'escapes', leaving a bloody trail of designers and quality
assurance people in its wake."
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message