Verständisfrage: Block size des Filesystems

[dante]

Hallo zusammen,

vielleicht kann jemand Licht in mein Dunkel bringen:

Ich teste gerade die I/O-Performance eines virtuellen Testsystems mit Hilfe von iozone (http://www.iozone.org/).

Unter Anderem fahre ich Tests, welche die write- und re-write Performance testen. Die Testfiles sind 1GB, 2GB, 4GB und 8GB groß, ich nutze bei iozone selbst die Blockgrößen 1KB, 2KB, 4KB, 8KB und 16KB.

Das Testsystem ist ein Ubuntu 10.04 LTS 64 Bit mit 2.6.32er Kernel. Ich nutze dort LVM und das ext4 Filesytem, die Blockgröße des FS ist 4KB.

Folgendes habe ich beobachtet:
Bei allen Tests ist die re-write Geschwindigkeit bei der iozone Blockgröße von 1KB und 2KB grottenschlecht (um die 20MB/s, Referenz bei größerer Blocksize: ~125MB/s).


Daher meine Frage: Was macht das Filesystem (bzw. iozone?) mit den Dateien, wo die Test-Blockgröße kleiner ist, als die des Filesystems selbst?

Gruß
dante

[papabaer]

Es nutzt einen kompletten Block, auch wenn die Datei kleiner ist. Wenn du also bei einer Blocksize von 4kb 1000 Dateien schreibst, die nur 2kb groß sind, hast du trotzdem 4000kb belegt.

Ob nutzen in diesem Fall allerdings auch schreiben heißt, müssen andere beantworten.

[dante]

Daran hatte ich auch gedacht, aber das widerspricht sich mit der write-Performance, die ist nämlich ok.

Die Einbrüche habe ich nur beim re-write, was mich sowieso wundert, denn durch das Caching sollte das um einiges flotter passieren (tuts auch, nur nicht bei einer Testblockgröße von 1KB und 2KB).

[Joe User]

Nimm mal XFS und JFS statt Ext als Filesystem und lasse danach auch mal LVM weg, das dürften interessante Ergebnisse liefern ;)

[rudelgurke]

Die Einbrüche habe ich nur beim re-write, was mich sowieso wundert, denn durch das Caching sollte das um einiges flotter passieren (tuts auch, nur nicht bei einer Testblockgröße von 1KB und 2KB).

Dass müsste daran liegen wie die kleineren Testdaten in den Blöcken abgelegt werden.
Wenn ich mich recht erinnere belegt ein 4 KB Block 4 KB, auch wenn kleinere Daten reinkommen. Theoretisch könnte man in den 4 KB Blöcken auch 2 2KB Daten ablegen, allerdings macht dann die Perfomance Probleme weil die Verwaltung zu groß wird. Bleiben also 2 KB bzw. 3 KB pro Block frei, auch nicht ideal weswegen wohl beim Re-Write die Performance mit 4 / 8 oder 16 am Besten sein dürfte, da dort immer die 4 KB Blöcke voll belegt sind und die interne Verwaltung flach fällt.

Gab da irgendwo einmal eine sehr ausführliche Beschreibung, ist mir allerdings entfallen wo :(

[dante]

Nimm mal XFS und JFS statt Ext als Filesystem und lasse danach auch mal LVM weg, das dürften interessante Ergebnisse liefern ;)

Was hättest du jetzt erwartet?
Ich habe eben mal ein (gleichkonfiguriertes) Testsystem mit xfs mit ohne LVM hochgezogen, Performance sieht in der Streuung ziemlich gleich aus, re-write bei Blöcken <4KB ergibt ein gleiches Bild.

Soll ich noch JFS testen oder verrätst du mir den Hintergrund deiner Aussage :p

[Joe User]

Im Regelfall ist XFS deutlich performanter bei vielen kleineren Files, daher ist Dein Test nicht eindeutig pro XFS. Ich hatte schlicht übersehen, dass Du mit Monsterfiles testest ;)
LVM bremst etwas, da es eine weitere zu durchlaufende Softwareschicht bedeutet.

Also ignoriere einfach meinen vorigen Einwand.

[dante]

Aha, trotzdem gut zu wissen.
Da es aber auch um einen Webserver geht, der unter diesen Bedingungen laufen soll, wäre das XFS gar nicht mal uninteressant.

Zu bemerken ist auch: das Ganze läuft virtuell, auf einem ESX-Cluster, wo der Storage im SAN liegt.

[Joe User]

OK, Cluster mag XFS wiederum nicht ganz so gerne, da würde ich eher zu echten Cluster-Filesystemen greifen. Oder liegt der Storage vollständig und ungeclustert im SAN? Dann käme XFS doch noch in Betracht...

Wichtig bei XFS: Immer die aktuellsten XFS-Progs verwenden, gerade Debian/Ubuntu liefern gerne völlig veraltete und verbugte Versionen aus.
http://oss.sgi.com/projects/xfs/
ftp://oss.sgi.com/projects/xfs/cmd_tars/

[dante]

Sorry, habe mich wahrscheinlich falsch ausgedrückt.

Mein Test-System selbst ist eine VM auf dem ESX-Cluster, nicht derselbige als solches ;-)

Das Test-System soll nicht geclustert werden, sondern einer von n loadgebalancten Webservern werden. (Wenn die Performance in der virtuellen Umgebung das hergibt).

Die Ubuntu Repos geben in der Tat saualte Versionen her, d.h. aber, ich müsste mir meinen Kernel (mit den neusten XFS Sourcen) selbst kompilieren?

[Joe User]

Nein, es geht nur um die xfsprogs zum Anlegen und Warten des Filesystems. Der aktuelle Debian/Ubuntu-Kernel ist in diesem Fall noch aktuell genug.

[dante]

Moin,

nochmal die Nachfrage:
Was sind für dich "kleinere" Dateien?

Ich hätte noch Middleware-Kisten zwischen Webserver und ERP-System, die mit XML-Dateien zwischen 1MB und ~20MB jonglieren.
Da würde es in meinen Augen auch durchaus Sinn machen, mal JFS oder XFS zu testen.
Einwände? :-?

Gruß
dante

[Joe User]

Mit "kleineren Dateien" meine ich vorwiegend Dateien <=1MB, wobei man es bei Deiner Middleware-Kiste durchaus auf einen Versuch ankommen lassen sollte.
XFS ist insbesondere bei Web- und Mailservern die erste Wahl und auch bei Fileserver mit vielen kleineren Dateien eine gute Wahl.
XFS macht eigentlich alles das richtig, was ReiserFS falsch gemacht hat und läuft zudem deutlich stabiler (selbst Strohmausfälle überlebt XFS in der Regel unbeschadet, was bei Ext[234] und ReiserFS ja immer problematisch ist).

Mit JFS habe ich vor rund 6 Jahren mal kurz experimentiert und fand es damals zwar änlich brauchbar wie XFS, bin dann aber doch bei XFS geblieben. Ob JFS heute noch taugt, kann ich also nicht wirklich beurteilen.