[User-Review] Performanceunterschied mit aktuellem Raidcontroller bei Cache Ein/Aus

[AssassinWarlord]

Servus, vielleicht interessiert es den einen oder anderen hier ja auch wie ein halbwegs aktueller Raidcontroller heutzutage so performt in den verschiedenen Raid-Leveln wenn man den Cache aktiviert oder deaktiviert. Hatte die Tests eigentlich nur für mich selber gemacht, aber kann ja mal nicht schaden das mit online zu teilen
Gibt ja mancherorts das Gerücht, dass z.B. bei nem Raid5 nur so schnell geschrieben werden kann, wie ein einzelnes Laufwerk maximal kann...was so nicht ganz richtig ist und ich das mit Benchmarks und real-Szenario Tests einfach mal widerlegen wollte. Das Raid ist nicht nur solange schnell bis der Cache voll ist - der ist nahezu immer deutlich schneller mit aktivem Cache (WriteBack Cache).
Daher einmal mit aktiven Cache & ReadAhead getestet und einmal mit deaktivierten Cache & ReadAhead soweit es möglich war (also einmal alles an Raidcontroller optimierungen ein, und einmal alles an optimierungen aus, auch HDD Cache)

Testsystem besteht aus:
Intel Core i5-12600k mit deaktivierten E-Cores, auf einem Gigabyte Z690 UD mit 2x 8GB DDR5 4800Mhz Ram.
Als Raidcontroller hält ein Broadcom 9560-16i her, mit 8GB Cache welcher mit seinen vollen 8 Lanes bei PCIe 4.0 angebunden ist.
Als Festplatten habe ich zum testen 4x Seagate IronWolf NAS HDDs genommen mit je 2TB, 5900U/min und 64MB HDD Cache (ST2000VN004)
Der Primäre Datenträger von dem Gelesen und geschrieben wird besteht aus 3x WD SN700 NVMe SSDs mit je 4TB und das ganze im Intel VMD RAID 0 gesetzt dass es keinerlei Flaschenhals diesbezüglich gibt.




Ich habe jeweils zum testen einmal das Tool CrystalDiskMark genommen, aber um auch Real-Szenario workload zu haben auch mal einen Ordner mit knapp 96.000 Daten welcher ca. 13GB groß ist, und ein 50GB komprimiertes Image (also auch nichts mit gleichen blockinhalt oder dergleichen)

Betriebssystem war ein Windows Server 2022, welches selber ja schon ein Software Cache System mitbringt (was ich nicht deaktiviert habe, also alles auf Standard gelassen)

hier die Ergebnisse:



Einzelnachweise

Erstmal eine HDD einzeln, mit unterschiedlichen HDD Cache Einstellungen (Raidcontroller Cache geht beim JBOD nicht)

Cache aus	Cache Ein
Lesen: Schreiben: ​	Lesen: Schreiben:

RAID 0

Cache aus	Cache Ein
Lesen: Schreiben: ​	Lesen: Schreiben:

RAID 5

Cache aus	Cache Ein
Lesen: Schreiben:	Lesen: Schreiben:

RAID 6

Cache aus	Cache Ein
Lesen: Schreiben:	Lesen: Schreiben:

RAID 10

Cache aus	Cache Ein
Lesen: Schreiben:	Lesen: Schreiben:

Windows hat beim einzel-Datei Kopieren erstmal den RAM befüllt, daher der Peak am Anfang beim Schreiben (Windows hat da immer mit 1.7GB/s geschrieben).
Interessant ist auch, dass der Raidcontroller bei einem Nicht-Paritätsbasierendem Raid seinen kompletten Cache zum Burst genutzt hat was man beim CrystalDiskMark sieht, beim Raid5/6 hingegen scheint der Controller seinen Cache lieber freihalten zu wollen für die Berechnungen der Parität(en)

Man kann festhalten - für ein Fileserver wo man eigentlich nur große images drauf schreiben will, ist ein RAID5 schon sehr schnell, auch beim Schreiben. Selbst ein Raid6 ist recht schnell wenn man eine noch höhere Hardware-Ausfallsicherheit haben möchte. Über die einzelnen Raidlevel und die jeweilige Verfügbarkeit der Arrays wollte ich hier nicht weiter diskutieren, denke es sollte bekannt sein wieviel Laufwerke bei den jeweiligen Raidleveln ausfallen dürfen. Der Cache bzw. die Algorithmen die dahinter stehen um den Schreibprozess zu optimieren machen auch das Schreiben vieler kleiner Dateien sehr schnell

 

[Holt]

Gibt ja mancherorts das Gerücht, dass z.B. bei nem Raid5 nur so schnell geschrieben werden kann, wie ein einzelnes Laufwerk maximal kann

Wo denn? So einen Unsinn habe ich noch nie gelesen oder gehört.

Betriebssystem war ein Windows Server 2022, welches selber ja schon ein Software Cache System mitbringt

Den hat ein normales Windows wie Win 10 oder 11 auch.

was ich nicht deaktiviert habe

Dies können Benchmarks wie CDM auch selbst, die wollen ja die Performance des Datenträgers und nicht die des RAMs testen.

Windows hat beim einzel-Datei Kopieren erstmal den RAM befüllt, daher der Peak am Anfang beim Schreiben (Windows hat da immer mit 1.7GB/s geschrieben).

Nicht geschrieben, sondern gelesen, denn die angezeigte Geschwindigkeit beim Kopieren mit dem Explorer basiert auf dem gelesenen Datenvolumen. Hier hatte ich das gerade erst am Freitag beschrieben.

 

[AssassinWarlord]

Einige Raid Calculator Websites besagen das, und Vieleicht auch darum hält sich das Gerücht hartnäckig in so manchen Köpfen der User in den verschiedenen foren
Ja raid 5 fordert glaube ich 4x IOPS, raid6 halt 6x IOPS aber deswegen ist nicht gleich alles langsamer...


Und ja stimmt, Windows 10/11 macht das mit dem internem Caching genauso ^^

 

[Holt]

Einige Raid Calculator Websites besagen das

Das Internet ist voller Blödsinn, man kann nicht alles kommentieren, geschweigen den korrigieren!

Ja raid 5 fordert glaube ich 4x IOPS, raid6 halt 6x IOPS aber deswegen ist nicht gleich alles langsamer...

Das ist die Write Penalty, es müssen halt bei RAID5 oder 6 alle Daten von allen anderen Platten an der Stelle gelesen werden, wenn auf einer der Platten dort Daten überschrieben werden um die neuen Parity Daten berechnen zu können, die dann auch noch geschrieben werden müssen. Aber dies ist nur nötig, wenn nur ein Teil des RAID Chunks überschrieben wird, überschreibt man einen ganzen Chunk, so spielen die alten Daten und damit auch die alten Parity Daten für diesen Chunk keine Rolle mehr und der RAID Controller kann die neuen Parity Daten aus den Daten in seinem Cache berechnen, ohne dafür irgendwas von den Platten lesen zu müssen und kann dann so schnell schreiben, wie es diese Daten auch lesen könnte.

Für die letzte Aussage muss man bei SSDs aber eine Einschränkung machen, denn solche professionellen RAID Controller mit DRAM Cache haben normalerweise eine BBU und deaktivieren den Schreibcache der Laufwerke, denn der wäre ja bei eine, unerwarteten Spannungsabfall im Gegensatz zum DRAM Cache des Controllers dann nicht geschützt. Bei Client SSDs sollte dann die Schreiraten massiv leiden, bei 4k QD1 reden wir dann von einstelligen MB/s Werten, statt im besten Fall weit über 100MB/s. Sollte, denn mache von denen machen auch Sync-Faking, ignorieren also die Befehle ihren Schreibcache zu leeren und tun so als hätten sie dies gemacht, selbst wenn die Daten noch im Schreibcache und nicht im NAND stehen, was nur "erlaubt" ist, wenn die SSD eine Full-Power-Loss Protection hat, was für Enterprise SSDs normal ist.

Wer also Consumer SSDs an solchen HW RAID Controllern betreibt, sollte sich über eine miese Schreibperformance nicht beschweren und dies auch nicht zwangsläufig an der Write Penalty. Enterprise und Consumer zu mischen birgt eben immer Risiken.