[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [OT] Performance von RAID und Dateisystem



Hallo,

>16 * 1TB SATA2 (WD Raid Edition 3 und 4, 7,2krpm) in einem Infortrend
>A16S-G2130, verbunden mit einem HP DL360g6 über SAS, 3Gbit. Der DL360
>hat 8GB RAM und einen Xeon 5506 mit 4 Cores. Das Betriebssystem hat
>extra nochmal 2 SAS-Platten im RAID1 Der SAS-Connector zum Infortrend
>ist ein LSI Logic / Symbios Logic SAS1068E PCI-Express Fusion-MPT SAS
>(rev 08), laut lspci. Weiterhin ist eine kleine Tape-Library (LTO5) von
>HP angeschlossen.
>
>Aktuell läuft dort ein RAID1+0 (jetzt gerade 2 * 8 Platten im RAID0 und
>ein RAID1 drüber) mit einer Stripe-Size von 512K.

Das RAID Setup klingt für mich suboptimal. Wenn eine Platte kaputt ist,
ist das gesamte RAID0 unbrauchbar, und es darf keine Platte aus dem
anderen RAID0 Verbund gleichzeitig ausfallen, ansonsten ist das System
unbrauchbar.

Wenn du ein RAID1+0 willst, würde ich eher 8x RAID1 bauen und darüber
stripen. Wenn dann eine Platte ausgefallen, darf eine aus 14 der 15
verbleibenden ebenfalls ausfallen, ohne dass das System unbrauchbar
wird.

Allerdings frage ich mich, ob man sich hier mit RAID1+0 wirklich einen
Gefallen tut. Jede Festplatte sollte mindestens 60 MB/s schaffen, beim
Striping über 8 Platten also 480 MB/s. Die 3Gbit/s SAS Anbindung des
RAID Controllers an den Server schafft aber höchstens 375 MB/s.

Der Performanceverlust beim Wechsel auf ein RAID5 ist vermutlich kaum
messbar. Umgekehrt ermöglicht ein RAID5 aber ein größeres Filesystem
und damit ein geringeres Risiko für Fragmentierung. Beim RAID1+0 ist
das FS 8 TB groß, bei einem RAID5 mit Hotspare hättest du 14 TB zur
Verfügung. Eine Datenmenge von 6 TB wären also 75% Belegung beim
RAID1+0 oder 43% bei RAID5.

>Das Dateisystem ist
>ext4 mit Standardoptionen. Installiert ist ein Debian Squeeze mit
>2.6.32-5-openvz-amd64.

Ist OpenVZ auf dem Backupserver wirklich nötig? Ansonsten würde ich
den normalen amd64 Kernel nehmen. Das spart den Virtualisierungs-
Overhead (ca. 2-3%) und ermöglicht es außerdem, testweise einen
neueren Kernel einzusetzen, z.B. den 3.2 aus Wheezy.

Ich könnte mir vorstellen, dass XFS anstelle von ext4 hier noch
ein bisschen mehr Performance ermöglicht. Das Filesystem sollte mit
der Option noatime gemountet sein. Als I/O Scheduler würde ich deadline
oder noop wählen, anstelle des cfq, das per Default aktiv ist.

>Mein Test mit dem aktuellen RAID-Level brachte weit weniger als 15MB/s.
>Als mein Kollege den gleichen Test nur leicht abänderte und nur pv(1)
>zwischen tar und /dev/null stellte, kam ich auf ~60MB/s. Was ist da los?

Durch die Pipe wird das Schreiben nach /dev/null in einen eigenen Prozess
ausgelagert. Das bewirkt aber höchstens Faktor 2.

Ist denn der Job auch wirklich in einem Viertel der Zeit fertig? Kann es
sein, dass dstat hier einfach zusätzlichen I/O für die Pipe dazugerechnet
hat? Was passiert, wenn du "pv" durch "cat" ersetzt?

Gruß, Harald


Reply to: