[linux-l] mbox/Maildir/tar

[Steffen Dettmer]

* Ralph Angenendt wrote on Thu, Nov 29, 2007 at 10:32 +0100:
> Das Problem ist, dass in Lastsituationen nicht "hin und wieder"
> gewritten wird. Man kann mit iostat dann durchaus feststellen, dass der
> meiste Platten-I/O dann *auf* die Partition draufschreibt. Und das kann
> nicht das refreshen des Caches sein, als uns das aufgefallen ist, waren
> bei uns eigentlich "nur" zwei Seiten stark nachgefragt. Ach ja,
> sustained output in Richtung Internet waren 80Mbit - allerdings mit 2
> Proxies. 

Das ist interessant. Mit angenommenen 50% cache hits (war mal ein
praktischer Wert, heute würde ich eher weniger erwarten, wegen dieser
ganzen dynamischen Seiten, Banner etc) kann man ganz mutig und frech
(und falsch) auf 80 MBit intern hochraten ähh hochrechnen, das
Filesystem schafft vermutlich 50-100 (oder eben auch 150) MB/sec, dass
ist also 10 mal mehr. Klar gibt es jeweils deutliche Overheads. Hätte
daher bei grösszügigem sync erwartet, dass das in die Zeiten passt, wo
nichts zu tun ist. Dabei würde der load natürlich grösser sein aber
kleiner 1 und der Durchsatz gleich. Sicher, wenn man längere synctime
mountet kann man auch noatime mounten und wenn man atime nicht braucht
ist das sicherlich eh besser.

> Durch remounten der Partition mit "noatime" ist die Last sichtbar
> runtergegangen.

Aber interessant, wie man (== ich) sich so verschätzen kann :)

> > Ich geh davon aus, dass man die sync Zeit vielleicht dann auch
> > gleich bissel hochstellt und auch bissel RAM hat.
> 
> Deswegen war ich ja so erstaunt, der Rechner hat 2,5GB RAM. Klar,
> Journal wegschreiben macht sich eventuell auch bemerkbar, aber wie
> gesagt: Wir haben eine klare Senkung der I/O-Last auf den Rechnern
> bemerkt.

Die Frage ist ja auch, wieviel er davon wofür benutzt. z.B. werden ja
auch cache misses object write outs ge-buffer-cacht, was man hier
eventuell gar nicht will. Ich erinnere mich nicht mehr genau, aber
machte squid das object write nicht auch asyncron? Da kann man bestimmt
viel tunen (auch nach noatime noch), glaube ich. Interessantes Thema.

> Das sind dann natürlich eher Extremsituationen, klar. Im "normalen"
> laufenden Betrieb hat sich das auch nie bemerkbar gemacht.

Ja klar. Das war ja auch mein Punkt ein paar Mails weiter vorn, wenn man
hohe Anforderungen hat, muss man optimieren. Mit mount optionen kann man
das machen - aber muss ja nicht. Daher finde ich die Möglichkeit von
noatime prima, auch wenn man sie wohl sehr selten nutzt. Sagen wir mal
flash, DVD RAM, grosse exklusive caches und grosse exklusive maildir
filesysteme :-)

> > Ich würde erwarten, dass das mehr bringt als noatime - stimmt das?
> 
> Kann ich dir nicht sagen - mehr RAM hatten wir nicht :)

2,5 GB ist doch aber schon fett?! Sinnvoll wird davon sicherlich nur ein
kleiner Teil genutzt. Das ist ja das Problem, wenn man eine (1) genaue
Anwendung hat, muss der generische Algorithmus ja nicht gut sein
(passen)... Für squid könnte man z.B. sogar in Erwägung ziehen, ein
dummes filesystem zu verwenden, weil man braucht da ja nur performance,
vielleicht ist am Ende gar ein schlichtes vfat am schnellesten.
Schlimmstenfalls geht eine Datei verlorern, was ja /hier/ sogar ziemlich
egal ist :)

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.