Deine Fragen decken ein relativ weites Feld ab, erschöpfend kann ich darauf gar nicht eingehen, aber vielleicht helfen Dir meine spontanen Gedanken ja schon etwas weiter:

1) Ich glaube, viel flinker als ein ext4 wird es nicht mehr werden. Btrfs ist noch nicht fertig, ext2 bringt gerade bei großen Dateisystemen keine Vorteile mehr, ZFS unter Linux geht nicht wirklich gut und ZFS ist auf Zuverlässigkeit und nicht auf Performance ausgelegt. Du kannst natürlich schauen, ob Du mit ReiserFS oder XFS bessere Ergebnisse bekommst, aber ich fürchte es wird in keinem Verhältnis zum Aufwand eines Dateisystem-Wechsels stehen. Verwende „noatime“ und „nodiratime“, mehr kannst Du fürchte ich nicht machen.

2) Du könntest versuchen, die Blockgröße des Dateisystems auf die Blockgröße des RAIDs, jene auf die der Partitionen und diese auf die Blockgröße der Festplatten abzustimmen, das nennt man alignment. Ich hab mich mit sowas schonmal beschäftigt und das ist äußerst komplex und knifflig. Das würde ich an Deiner Stelle in jedem Fall auf einem Testsystem üben. Du wirst auch eine Menge Dokumentation wälzen müssen und viel googeln. Als i-Tüpfelchen kann dann anschließend noch die Größe der Caches und Buffer von mdraid so eingestellt werden, daß sie perfekt zu den Blockgrößen passen. Alles zusammen kann aus einem mdraid noch etwas Performance rauskitzeln, aber meiner Erfahrung nach bringt das nur bei einem Raid5 oder Raid6 wirklich viel, bei einem Raid0 oder Raid 1 oder Raid10 halten sich die Ergebnisse doch sehr in Grenzen.

3) Da würde ich bei einem Produktivsystem die Finger von lassen. Wenn dann würde ich sowas vorher auf einem Testsystem intensiv testen wollen.

4) Bei einem Raid0 wird die Schreiblast auf mehrere Festplatten verteilt, das kann eine Menge bringen. In dem Fall bringen mehr Festplatten auch in der Tat mehr Leistung, getreu dem alten Witz „statt daß eine Frau 9 Monate braucht für ein Kind, lassen wir jetzt 9 Frauen einen Monat lang dran arbeiten“. Da ein Raid0 aber keine Redundanz mehr bietet, bevorzugen wir in der Regel Raid10, ein Raid 0 über zwei Raid1.

Insgesamt bringen Raid-Controller meist bessere Leistung als mdraid, auch wenn ich mdraid aufgrund der hohen Flexibilität und Zuverlässigkeit eigentlich klar bevorzuge. Aber ein Raid-Controller hat nunmal einen dedizierten Prozessor und eigenen RAM, mdraid muß immer mit anderen Prozessen um diese Resourcen konkurrieren. Gerüchten zufolge läuft aber auf den Raid-Controllern einiger Hersteller ein Linux mit mdraid.

Was Raid-Controller angeht, sind wir derzeit von den neueren Adaptec-Controllern begeistert, die statt einer BBU (einer Batterie die den Cache-Inhalt bei Stomausfall eine Weile halten kann) einen Kondensator und einen kleinen Flash-Speicher haben. Bei einem Stromausfall liefert der Kondensator genug Energie, um den Cache-Inhalt in den Flash zu schreiben. Man ist also nicht mehr davon abhängig, daß der Strom wiederhergestellt wird bevor die BBU leer ist und der Kondensator hält Jahre bis Jahrzehnte und muß nicht dauernd ausgetauscht werden wie eine BBU.

Zum Testen von Festplatten-Performance auf Testsystemen habe ich mit „bonnie“ gute Erfahrungen gemacht. Es simuliert verschiedene Arten von Last und kommt damit einer echten Workload halbwegs nahe.

Viel Erfolg,

Christopher

bald gehe ich dir bestimmt schon mit meinen Fragen auf den Geist. Trotzdem, ich will’s vom Profi wissen. ;)

Ich hab hier ebenfalls eine Webhosting-Kiste stehen, die gelegentliche ihre iowait-Probleme hat. SSDs würden das Problem lösen, sind aber leider im Rahmen des Projekts unbezahlbar (über 600 GB Daten).
Konkret reden wir hier von 50-100 IOs pro Sekunde, was den beiden Platten (im Soft-RAID1) schon gut zu schaffen macht; die sind definitiv am Limit. Und wenn dann ein kleiner Peak kommt, bei welchem kurzfristig mehr IOs kommen, kommen die Platten gar nicht mehr hinterher, iowait steigt in Richtung 30% und katapultiert die Load in unschöne Höhen.
Leider kann ich diverse Sachen nicht einfach testen (Downtimes sind nicht drin und einen Testserver gibt es nicht), weshalb mich hier deine Meinung interessieren würde.

1) Es läuft aktuell ein ext4, und das dank einiger „riskanter“ Mount-Optionen auch deutlich besser als vorher. Macht ein anderes Dateisystem hier vielleicht Sinn?
2) Wie sieht es mit den Blockgrößen des RAIDs / des Dateisystems aus? (Da blicke ich eh nicht so recht durch, mag sein, dass ich was durcheinanderwerfe :P)
3) Hast du Erfahrungen mit Flashcache oder ähnlichen „Kernelpatches“? Ich bin echt unsicher, ob ich das wagen soll…
4) Um mal auf deinen (mal wieder guten!) Blogartikel zurückzukommen: In deinem Kommentar sprichst du von einem RAID0 als „Lösung“. Das wundert mich aber – wie kann das RAID etwas an der Situation verbessern? Die Platten werden ja (mechanisch) nicht schneller. Ich hatte echt gedacht, dass ein RAID0 quasi nur Verbesserungen bei großen Daten im Hinblick auf den Durchsatz macht. Der Durchsatz ist bei mir natürlich mit ~ 2 MB/s kein Problem.

Das wäre es auch schon mit der Fragerei. Würde mich freuen, wenn du kurz drauf eingehen könntest. :)

Grüße
Tim

vielen Dank für deinen Kommentar. Ganz klar: In die Details, wie genau sich die Last zusammensetzt, geht der Artikel nicht; das würde sicher auch genug Stoff für einen eigenen Artikel bieten. :-)

In der Praxis stehen wir auch viel häufiger vor dem Problem, dass es akute Schreiblast-Peaks gibt, die aber schwer zu analysieren sind, weil es im Gegensatz zum Prozess-Accounting bei den meisten Distributionen keine vernünftigen Möglichkeiten gibt, auch I/O einem Accounting zu unterziehen. Manchmal ist das schlicht Glückssache, so wie bei einem Vorfall aus 2008. Inzwischen bin ich vor längerer Zeit über iodump gestoßen, was rudimentäres I/O-Accounting bietet, wenn die eingesetzte Distribution kein iotop o.ä. hat.

Klar ist ein RAID0 anfällig für Probleme. Dafür haben wir aber die DRBD-Redundanz drübergebaut. Vermutlich werden die fraglichen Geräte ohnehin durch Varianten mit 4 Platten im RAID10 ausgetauscht.

Das Problem mit dem RAM ist in diesem konkreten Fall, dass das keine Maschine ist, auf der irgendwie wenige definierte Applikationen laufen, die man diesbezüglich dann auch entsprechend vorbereiten könnte, sondern es ist ein generischer Hosting-Server, bei dem, platt gesagt, die Arten der darauf einprasselnden Belastungen jeden Tag aufs Neue eine lustige Überraschung darstellen. Längeres Debugging mit laufendem iostat haben nebenbei gezeigt, dass Leselast in der Regel recht gleichmäßig ist und kaum Probleme macht – die iowait-Peaks ließen sich jeweils mit Schreiblast-Peaks in Verbindung bringen. Insofern würde mehr RAM in diesem konkreten Fall vermutlich kaum etwas bringen, auch wenn du im Allgemeinen damit natürlich völlig recht hast. Im Zweifelsfall dürfte aber schließlich ein RAID-Controller mit BBU-gestütztem Schreibcache vermutlich mehr Performance bringen.

RAID-0 ist natürlich sehr praktisch, wenn man viel Lese-Last hat und die Blocks von beiden Platten parallel gelesen werden können. Hierbei kann es jedoch immernoch sehr schnell zu hohem IO-Wait kommen, wenn sehr viele parallele Anfragen kommen und der Suchkopf trotzdem über die ganze Platte lesen muss. Oft ist an der Stelle mehr RAM besser, als auf ein anfälliges RAID-0 zu wechseln. Heute kosten 64 GB RAM kaum was und es passen fast alle „aktiven“ Daten rein und die Platte muss gar nichts mehr lesen, sondern nur noch schreiben.