Ich halte den Wechsel auf EXT3 erstmal nicht für zielführend, weil ich denke, dass damit nur an den Symptomen gewerkelt wird.
Der jdb2-Thread ist für das Journaling des Filesystems zuständig. Das Journal ist ein kleiner Bereich (default 128MB), in dem die Änderungen kompakt reingeschrieben werden, bevor sie dann aufwendig in möglicherweise vielen Verzeichnissen und Dateien vorgenommen werden. Man kann das Journal zwar abschalten, aber eigentlich will man das nicht, weil das Journal einen kompletten Filesystemcheck nach einem Crash überflüssig macht. EXT3 nutzt aber auch ein Journal, d.h. mit dem Wechsel auf EXT3 ändert sich inhaltlich gar nicht so viel (der Thread nennt sich dann einfach [kjournald]).
Die 99% bei iotop sind nicht das Problem, da wir ja über eine schreiblastige Nutzung reden. Als problematisch sehe ich eher, dass dabei nur 16-113 KB/sec Durchsatz erreicht werden. Und damit sind wir wieder bei der Performance der Platte.
Am Output von
parted sieht man, dass die Platte zum Server hin mit 512 Byte großen Sektoren arbeitet, aber intern mit 4096 Byte großen Sektoren läuft. Für mich ist noch nicht endgültig ersichtlich, ob da nicht ein Problem mit dem Alignment vorliegt.
EXT3/EXT4 arbeiten per Default mit 4K Blocks, d.h. jeder I/O wird als Block von 4K an die Platte übergeben. Die Blockgröße kann man bei der Erzeugung des Filesystems festlegen. Zur Sicherheit kann man das nochmal verifizieren:
Code:
# dumpe2fs -h /dev/md/0
...
Block size: 4096
Fragment size: 4096
...
Wenn hier 4096 auftaucht, dann ist die Größe schonmal passend. Jetzt kommt es noch drauf an, dass die 4K vom Server auch genau in die 4K der Platte kommen. Wenn das nämlich nicht passgenau zusammentrifft, dann
- müssen zuerst zwei Sektoren von der Platte eingelesen werden
- die ersten 512 Bytes vom Server an die letzten 512 Bytes des ersten Sektors kopiert werden
- die folgenden 3584 Bytes vom Server an die ersten 3584 Bytes vom zweiten Sektor kopiert werden
- beiden Sektoren wieder zurückgeschrieben werden
Das ist auf
http://www.thomas-krenn.com/de/wiki/Partition_Alignment ganz anschaulich dargestellt.
Leider ist die Ausgabe von
parted durch die Anzahl der Gigabytes nicht mehr genau genug. Nach dem Aufruf von
parted läßt sich mit nachfolgenden Kommandos die Ausgabe auf die Anzahl der Sektoren umschalten und für sda anzeigen:
Code:
select /dev/sda
unit s
print
Das Alignment stimmt, wenn die unter Start aufgeführten Zahlen (das "s" am Ende natürlich weglassen) glatt durch 8 teilbar sind. Das oben beschrieben Problem tritt auf, wenn das nicht glatt aufgeht. Ich vermute, dass hier insbesondere die Partition Nummer 3 das Problem hat.
