Interessant wird es höchstens, wenn man ganze Subsysteme aus dem Kernel wirft (z.B. Sound).
Warum?
Letztendlich sind die Peformance Unterschiede durch einen minimalen Kernel --> minimal.
Die Frage wäre, wie minimal sie sind.
Die Optimierung auf deine CPU kann aber je nach CPU und Anwendungsfall deutlichere Performance Unterschiede bringen.
Nie gehört. Hast du irgendwelchen Lesestoff dazu? =)
du möchtest aus der Hardware das Maximum herausholen? [..]
Für die maximale Performance könntest du dann noch eine kleine (SLC-)SSD (z.B. Intel 313) als Caching-Device nutzen, was aber natürlich mit Zusatzkosten (ggf. 15€ für's Flexi-Pack + 15€ für die SSD) verbunden wäre.
Noch mal: Ich möchte möglichst viel aus der Hardware herausholen und eine für den Betrieb ausreichende Geschwindigkeit erzielen sowie mich im Zuge dessen mit ein paar für mich neuen Dingen auseinandersetzen. Das Nonplusultra wird hier nicht gesucht, und an der Hardware wird auch nichts geändert. Das ist nicht meine Entscheidung.
Wenn er die Geldgeber schon nicht von dem Sinn eines HW Raid Controllers überzeugen kann (den ich der Flexi+SSD Konfiguration vorziehen würde), dann wirds mit anderen HW Änderungen auch nix.
Richtig - und ganz einfach: Weil's nicht notwendig ist.
Es gibt für den Betreiber keinen Grund, in nicht notwendige Dinge Geld zu investieren.
Ich habe das aus den geposteten dd-Tests geschlossen, da sind es nur lineare Schreibzugriffe. Aber gut, falsch verstanden.
Sorry, mein Fehler. Das war meinerseits nur ein "Reinschnuppern" in die Geschwindigkeit und sollte nicht als Benchmark oder Darstellung der Ansprüche ans System gelten.
Ideal ist eben der Fall wenn immer ein komplettes Stripe Set geschrieben wird.
Entweder bin ich komplett auf dem Holzweg (was nicht auszuschließen ist
), oder wir reden aneinander vorbei. Deine Aussage ist meinem jetzigen Wissensstand nach dann korrekt, wenn man viel Durchsatz (also MB/s) will, da sich dann alle Platten mit dem "perfekten" IO beschäftigen. Was wir hier aber brauchen sind IOPS, sodass es eben
nicht perfekt sein dürfte, wenn sich mehrere Platten um ein und denselben Request kümmern - denn in dem Moment stehen ja für weitere Requests weniger bis keine Platten zur Verfügung. Und genau das möchte ich mich einer Chunksize > durchschnittlicher Request verhindern, sodass mir möglichst viele Platten für möglichst viele IOPS zur Verfügung stehen.
Wobei ich jetzt hier vom Lesen spreche und das mit dem Schreiben auch vermutlich noch nicht ganz verstanden hab...
Das ist auch der Grund wieso ein Raid-Controller mit Speicher und BBU einen auffälligen Performance-Vorteil hat.
Was hat das jetzt mit Stripe- / Chunksize zu tun?
Bzw. Performance würde ich testen, ob Du mit einer Chunksize kleiner 512k besser fährst. Derzeit ist dein Stripe Set 3MB groß, das ist schon recht viel für einen kompletten, Zusammenhängenden IO.
Siehe oben. Würde mich über eine Erläuterung freuen; auch, was den Unterschied zwischen lesen & schreiben angeht.
Grundsätzliche Tipps bzg. RAID5:
- habe immer ein gutes Backup
- regelmäßig die Konsistenz prüfen
- SMART-Werte der Platten im Auge behalten
Wie gesagt: Das MogileFS speichert die Daten redundant.
RAID-Checks sind ja eh bei Debian "ab Werk" dabei und werden auch durchgeführt, ebenso wie regelmäßige SMART-Langtests und Kontrolle der Werte.
Wenn Du 1 Chunk schreibst und deswegen die anderen 5 lesen muss hast Du 7 IO-Vorgänge (Parität mit eingerechnet), aber nur 1 Chunk geschrieben.
Oh Gott.
Wieso muss ich denn dann die anderen lesen? Kannst du das genauer erklären?
Wenn Du 6 Chunks (= Stripe Set) schreibst hast Du auch 7 IO-Vorgänge, aber 6 mal soviel durchsatz (weil Du 6 Chunks auf die Platte bekommen hast statt nur eines).
Geht es hier ausschließlich um verlorenen Durchsatz? Dann wäre das ja in meinem Fall nicht schlimm. Wobei ich jetzt hier wiederum nicht verstehe, wieso man in diesem Fall nichts "Anderweitiges" lesen muss, oben aber schon.
Noch mal zum Artikel über XFS:
http://www.pro-linux.de/news/1/17945/xfs-greift-nach-dateisystem-krone.html
Ist das nur "Kosmetik", weil sie jetzt per Default "gefährliche" Einstellungen setzen, die in anderen Dateisystemen erst aktiviert werden müssen und so in Tests einfach schneller
wirken? Ist halt interessant, denn das Dateisystem ist mir persönlich erstmal egal. Nur XFS reizt mich wegen der frei wählbaren Blockgröße. ^^
(Und den Kernel muss ich eh updaten, denn sonst will ext4 ohne Weiteres auch kein Riesen-Dateisystem anlegen.
)
) ist dein Raid bei jedem Schreibzugriff zusätzlich mit dem Lesen anderer Chunks des Stripsets beschäftigt, um die Parität neu errechnen zu können. Das kostet ganz böse Performance.
