RAID6 Linux Performance Optimierung

[gaelic]

Hallo.

Ich möchte gerne die Performance eines Raid6 Systems optimieren, weniger wichtig ist die Lese-/Schreibgeschwindigkeit, viel wichtiger ist mir die Latenz bzw. Access Time. Im Moment beobachte ich wenn ich einige festplattenintensive Scripts gleichzeitig laufen lasse, daß die Performance auf ein unterirdisches Niveau senkt.

Hier mal Angaben zum System:

• AMD Ryzen Threadripper 2950X
• GB X399 AORUS PRO-CF
• 4x Seagate Ironwolf 8TB - ST8000VN0022-2EL112 im Softwareraid 6
• Software: Ubuntu Bionic; Kernel 5.0.0-29; mdadm raid; btrfs als Filesystem

----

Meine Fragen nun: Wo kann und soll man tunen, sowohl System als auch Daten liegen (im Augenblick) auf dem Raid; Die Performance des Raids ohne Last ist imho ok, nur bei konkurrierenden Schreib- und Lesezugriffen bricht die Performance massiv ein.

Any thoughts?

 

[Mihawk90]

nur bei konkurrierenden Schreib- und Lesezugriffen bricht die Performance massiv ein.

Any thoughts?

Es sind Festplatten, da ist das nunmal so.
Wahlfreie Zugriffe sind nunmal keine Stärke von HDDs. Mechanik = langsam.

 

[Twostone]

Schon mal darüber nachgedacht, dem RAID eine SSD als Cache zur Verfügung zu stellen?

Außerdem: RAID6 und BTRFS? BTRFS kann RAID auf Dateisystemebene, ähnlich einem RAIDz2, warum nutzt Du nicht dieses, warum mdadm?

 

[gaelic]

Wahlfreie Zugriffe sind nunmal keine Stärke von HDDs. Mechanik = langsam.

Klar, nur ein Einbruch auf absolut unterirdisches Niveau bis hin zu einem quasi unbenutzbaren System erwarte ich dennoch nicht.

Schon mal darüber nachgedacht, dem RAID eine SSD als Cache zur Verfügung zu stellen?

Ja, aber ich will eben mal die Möglichkeiten ausloten.

Außerdem: RAID6 und BTRFS? BTRFS kann RAID auf Dateisystemebene, ähnlich einem RAIDz2, warum nutzt Du nicht dieses, warum mdadm?

Hätte das Vorteile? Was sind die Nachteile (Performance) von btrfs auf mdadm? Soweit ich gelesen habe ist das raid Konstrukt von btrfs noch nicht wirklich zu Empfehlen, btrfs an sich jedoch mittlerweile schon.

 

[Mihawk90]

Klar, nur ein Einbruch auf absolut unterirdisches Niveau bis hin zu einem quasi unbenutzbaren System erwarte ich dennoch nicht.

Das solltest du vielleicht mal in Zahlen ausdrücken. Denn wenn ich das lese:

wenn ich einige festplattenintensive Scripts gleichzeitig laufen lasse

Dann kann ich mir das schon vorstellen.

 

[Piktogramm]

Welche Optimierungen sinnvoll sind, hängt stark vom Anwendungsfall ab. Da müsstest du schon genauer verraten was du genau mit den Daten machst, wie diese strukturiert sind und wie häufig das Ganze abläuft inkl. ob Reboots dazwischen liegen oder nicht.

Caches können helfen, oder aber auch fast nichts bewirken. Wenn der Datensatz 10x größer ist als der Cache, bringt es halt nix. Wenn du immer nur die selben 1-20GB durchwühlst kann das der Ram eigentlich sauber abfangen (solang kein Reboot dazwischenkommt, da kann man aber auch tricksen, indem man nach direkt nach jedem Reboot den heißen Datensatz einmal durchwühlt und so in den Ram bringt)

UND, wenn du parallel Scripts laufen lässt, die sich bei I/O-Anfragen gegenseitig blockieren, dann forderst du das Ganze heraus. SSDs können sowas gut, HDDs nicht und Raids machen es eher schlimmer.

Edit: Bevor man anfängt irgendwelche Caches mit SSDs zu bauen, kann man oft auch gleich überlegen, ob man nicht die kritischen Daten + System gleich auf eine oder zwei SSDs legt.

 

[whats4]

einer muß es ja sagen:
primocache!

 

[Twostone]

Hätte das Vorteile?

Ein Rebuild auf FS-Ebene geht deutlich schneller als auf Geräteebene, da das Deteisystem weiß, wo Dateien abgelegt sind und wo unnötiger Datenmüll liegt und somit nicht den kompletten Inhalt nachbilden muß.

Was sind die Nachteile (Performance) von btrfs auf mdadm?

Mit mdadm hast Du noch eine weitere Schicht zwischen Datenträger, Dateisystem und Daten gestopft. Einfach ausgedrückt muß BTRFS die Daten an mdadm weiterreichen, welches diese dann letztlich irgendwann an den Datenträger reichen muß. Du kopierst im Zweifel über mehrere Puffer hinweg, Daten werden mehrfach (nutzlos) herumgereicht und die Latenz erhöht sich entsprechend, bis die Daten endlich dort landen, wo sie hin sollen. Vereinfacht ausgedrückt.

Soweit ich gelesen habe ist das raid Konstrukt von btrfs noch nicht wirklich zu Empfehlen

Wie weit der Ausbau mittlerweile produktionsreif ist, habe ich nicht verfolgt. Mein Kenntnisstand bei BTRFS ist in etwa zwei Jahre alt. Ich nutze immer noch ZFS, da sich über die Jahre dutzende von scripten zur einfacheren Verwaltung ergeben haben, die ich noch nicht umschreiben muß (und will, da es ziemlich viele Zeilen sind). So weit ich weiß, ist jedoch zumindest RAID5-Funktionalität im normalen^TM Rahmen (keine exotische Konfiguration) stabil nutzbar. Das ist aber, wie gesagt, schon mindestens zwei Jahre alt.

 

[rocketworm]

Im Moment beobachte ich wenn ich einige festplattenintensive Scripts gleichzeitig laufen lasse, daß die Performance auf ein unterirdisches Niveau senkt.

Das heisst also viele direkte Zugriffe gleichzeitig. Ein RAID 6 bringt bei direkten und Vorallem parallelen Zugriffen nur wenige vorteile.
Bei einem RAID 10, könntest du die Performance in diesem Szenario wahrscheinlich min. verdoppeln wenn deine RAID Lösung paralleles lesen unterstützt. Du hättest dann auch die CPU Last gesenkt, da die CPU die Paritätsdaten nicht mehr berechnen muss.

Ergänzung (17. Oktober 2019)

Des weiteren kannst du auch mal nen Benchmark welcher mit sequentiellen und parallelen Zugriffen testet auf deinem Array laufen lassen. Dann kann man sehen ob die Performance in Ordnung ist oder nicht.

 

[gaelic]

Des weiteren kannst du auch mal nen Benchmark welcher mit sequentiellen und parallelen Zugriffen testet auf deinem Array laufen lassen. Dann kann man sehen ob die Performance in Ordnung ist oder nicht.

Will ich noch machen sobald ich dafür Zeit habe. Gibt es empfehlungen diesbezüglich bis auf das obligatorische dd?

Danke mal für die Kommentare @Twostone

 

[Piktogramm]

@Twostone @gaelic
https://btrfs.wiki.kernel.org/index.php/Status

• BTRFS Raid56 sind nachwievor unstable [1]
• Der Overhead den mdadm mitbringt ist Größenordnungen kleiner als die Latenzen die HDDs mitbringen.
• Die neueren Ubuntuversionen bringen OpenZFS mit, ZFS könntest du also ebenso nutzen. Jedes noch so intelligente Dateisystem wird jedoch nichts dagegen ausrichten, wenn der Anwendungsfall der WorstCase für die Hardware ist.

[1] Man sollte lauffähige Konfigs bauen können, die zusätzliche Komplexität würde ich mir aber nicht geben.


Benchmarks kannst du dir schenken wenn du einen konkreten Anwendungsfall hast, dann teste gegen den. Und wenn du brauchbare Hilfe willst, leg möglichst viel vom Anwendungsfall offen -.-

 

[snaxilian]

Da du sowieso "nur" vier Disks verwendest hast du beim Raid 6 ja 50% netto übrig. Gleiches wäre bei einem Raid 10 der Fall. Vorteil: Mehr IOPS, schnellerer Rebuild. Nachteil: Es dürfen nicht mehr zwei beliebige Disks ausfallen sondern nur noch eine pro Mirror.
Ob ein Cache etwas bringt hängt wie gesagt von vielen Faktoren ab.

 

[Holt]

Mit mdadm hast Du noch eine weitere Schicht zwischen Datenträger, Dateisystem und Daten gestopft.

mdadm ist sehr schnell und ich wäre daher nicht sicher, ob das integrierte RAID von btrfs wirklich schneller wäre.

Es wäre sowieso die Frage ob btrfs für die Anwendung eine gute Wahl ist, es ist z.B. schnell beim Lesen kleiner Dateien auf Ordnern mit vielen Dateien, aber bei anderen Anwendungen dafür deutlich langsamer als andere Filesysteme und wenn dann noch mit Prüfsummen gearbeitet wird, ist die Performace richtig mies. Das generell schnellste Filesystem gibt es unter Linux sowieso nicht, jedes hat andere Stärken und Schwächen.

Bei einem RAID 10, könntest du die Performance in diesem Szenario wahrscheinlich min. verdoppeln wenn deine RAID Lösung paralleles lesen unterstützt.

Eben, bei nur 4 Platten ist RAID 6 totaler Blödsinn, außer man will künftig noch mehr Platten hinzufügen, denn bei RAID 6 hat man vor allem schreibend eine hohe write penalty und bei 4 Platten die gleichen 50% Nutzkapazität wie bei einem RAID 10.