AssassinWarlord
Lieutenant
- Registriert
- Okt. 2008
- Beiträge
- 1.010
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 :d
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)
RAID 0
RAID 5
RAID 6
RAID 10
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
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)
RAID 0
RAID 5
RAID 6
RAID 10
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