Raid 5 - Schreibrate sehr langsam

[Wildsau]

Hallo

Ich habe ein kleines Problem mit meinen Raid 5:

Mainboard: Asrock 890GX Extreme 3
Festplatte System: 2x WD 750GB als Raid 1 (funktioniert schon ewig)
Festplatte neues Raid 5: 3x Seagate ST2000DL003

Beim Lesen sind 250-300 MB/s drin. Beim Schreiben komme ich gerade mal auf lausige 10 MB/s

Nach etwas goggeln, habe ich festgestellt, dass bei manchen ebenfalls solche Probleme auftreten. Es wird immer zu "anständigen" Raid-Controllern geraten. Jedoch sind diese Threads schon teilw. mehr als 5 Jahre alt.

Für einen zusätzlichen Controller nochmal 200€ ausgeben, habe ich eigentlich keine lust.
Es muß doch so auch irgendwie gehen? Die 10MB/s können ja nicht alles sein.
Wenn dies "Stand der Technik" wäre, frage ich mich dann, wieso überhaupt Raid 5 bei den Mainboard-Chipsätzen angeboten und verkauft wird. So wie es jetzt ist, ist es absolut unbrauchbar.

Was mache ich falsch?

MfG
W!ldsau

 

[oggear51]

schalt mal den write cache an

 

[Wildsau]

Den bei Windows? "Schreibchache aktivieren" unter "Richtlinien?

Der ist schon aktiviert.

"Von Windows veranlasstes Leeren des Geräteschreibchaches deaktivieren" ist kein Haken drin. Macht aber auch kein Unterschied wenn ein Haken drin ist

MfG
W!ldsau

 

[uNreL2K]

Nenne mal die Werte der Stripesize, Clustersize, sowie die Werte des Alignments.

Wie misst du den Speed?

 

[Wildsau]

Habe mal ein Bild angegängt.

Den Speed messe ich mit Atto oder Everest Disk Benchmark.

Bei Everest DiskBench habe ich bei dem Raid 5 eine zugrifsszeit auf jeden Sektor von 0,00sek. Also auch ein unmöglicher wert.

MfG
W!ldsau

 

[Horsi]

Den Cachemode solltest Du möglichst auf "Write Back" stellen.

 

[Wildsau]

Den Cachemode solltest Du möglichst auf "Write Back" stellen.

Diese Option steht leider nicht zur Verfügung

Taugt das Raid Bios nichts? Treiber sind auch aktuell.
Kanns ja nciht sein dass nur ich da solche Probs hab.

MfG
W!ldsau

 

[uNreL2K]

Ohne Writeback-Cache beim Raid 5 sollte die Clustersize folgendem Schema entsprechen:

Stripesize * n-1

n=Anzahl der Memberdisks.

Beispiel: 5 HDDs im Raid 5
Stripesize: 16K
Clustersize: 64K

weil: 16K (Stripesize) * 5-1 (=4) ergibt 64K.

Leider ist die Größtmögliche Clustergröße 64K, und die kleinst mögliche Stripesize bei einem AMD Raid 64K.

Das drückt die Performance. Hier steht wieso: WD20EARS - (Soft)Raid5 mit SB750 - 4K Sektoren - ForumBase (Beitrag von Ernst@at)


Du hast also 128KB Stripe Size eingestellt.

Lade mal einen Screenshot vom Atto hoch.

Hast du das RAID in Windows Datenträgerverwaltung mit GPT oder MBR initialisiert?

Alignment herausfinden: AS SSD Benchmark starten (nicht den Benchmark sondern nur das Programm), Partition des RAID5 auswählen und Screenshot hochladen.

Clustersize herausfinden: Windowsbutton, "cmd" eingeben, cmd.exe mit Rechtsklick als Admin ausführen, "fsutil fsinfo ntfsinfo LAufwerksbuchstabe:" eingeben & Screenshot hochladen.

 

[Wildsau]

Habe das Raid 5 nochmal neu aufgesetzt und 64KB Stripe Block eingestellt.

In der Datenträgerverwaltung habe ich nach GPT initialisiert

Anbei AS SSD, Atto und cmd

MfG
W!ldsau

 

[uNreL2K]

Das Alignment passt. Lösche mal die Partition und stelle beim Formatieren bei der Zuordnungseinheit 64K ein. Bringt evtl. etwas Speed.

Gibt es nicht auch bei AMD einen Raid Configurator namens RAIDXpert, den man unter Windows ausführt? Dort kannst du evtl. den Writeback Cache anschalten.

 

[andichen]

Puh...das ist ja extrem. Also wenn das mit dem Schreibcache nicht geht, kannst du jetzt nur noch mal die 64K Clustergröße probieren. Vielleicht hilfts ja was, dass es zumindest etwas besser wird. Ansonsten kann man das vergessen, denk ich....

uNreL2K: Ich hab zwar nen Schreibcache und nicht solche Probleme, aber halt auch ein Raid5 aus 3 Platten. Könnte es noch etwas mehr bringen, wenn ich das auch nach dieser "Formel" dort einstelle? Momentan habe ich 64K-Stripes und die Standard-4K-Clustergröße. 32K Stripes kann ich am Controller auch einstellen, glaub ich. Könnte ich eigentlich gleich mal testen, sind ja noch keine Daten drauf...

 

[Schlingel_INV]

da fehlt write back. ob man das bei dir einstellen kann ist die frage. und wichtig: erst mal googeln was write back im falle von strom weg etc bedeutet.

ansonsten -> (passenden!!) contoller mit cache und iop kaufen

 

[BlackGhost]

Kannst du beim Erstellen des RAIDs nicht Write Back anstatt Write Through einstellen?
Ohne dem werden die Write Werte sich nicht ändern.

Stripe-Size vom RAID ist mit 128k schon richtig gewählt.
Die Größe der Zuordnungseinheiten von NTFS beim Formatieren auf Default (4096 Byte) belassen. Größere Zuordnungseinheiten werden erst bei >16TB Partitionen gebraucht.

 

[Wildsau]

Das Alignment passt. Lösche mal die Partition und stelle beim Formatieren bei der Zuordnungseinheit 64K ein. Bringt evtl. etwas Speed.

Gibt es nicht auch bei AMD einen Raid Configurator namens RAIDXpert, den man unter Windows ausführt? Dort kannst du evtl. den Writeback Cache anschalten.

Hat die Partition mal mit 64KB formatiert.
Siehe Anhang was passiert ist. Leider sind die Werte auch nciht das, was man erwartet.

Im RAIDXpert habe ich schon alles durchsucht. Writeback Cache kann man da leider nicht aktivieren
Schreibcache kann man dort aktivieren. Evtl. das gleiche?


MfG
W!ldsau

 

[BlackGhost]

Auch nicht direkt beim frischen Aufsetzen des RAIDs?

 

[oggear51]

NCQ kannst du auch einschalten,
mit solchen werten muss du leider mit onboard raid rechnen,
beim ICH10r chipsatz war es noch in ordnung da hatte ich ne performance von knap 130 mb/s

 

[uNreL2K]

uNreL2K: Ich hab zwar nen Schreibcache und nicht solche Probleme, aber halt auch ein Raid5 aus 3 Platten. Könnte es noch etwas mehr bringen, wenn ich das auch nach dieser "Formel" dort einstelle? Momentan habe ich 64K-Stripes und die Standard-4K-Clustergröße. 32K Stripes kann ich am Controller auch einstellen, glaub ich. Könnte ich eigentlich gleich mal testen, sind ja noch keine Daten drauf...

Ich persönlich nutze ein ein Intel Raid 5 bestehend aus fünf 2TB Samsung F4 Ecogreen ohne Write Cache. FakeRaids sind eh empfindlich und da brauch ich kein erhöhtes Risiko durch einen WriteCache. Die Performance ist für meinen Anwendungsfall auch top. Es liegen nur große Filmdateien darauf. Von 7,27 TB sind noch ca 1,5 TB frei, trotzdem sind es noch ~275 MB/s Write.

Der Grund, wieso die Clustersize nach der oben erwähnten Formal eingestellt werden sollte, ist folgender:

Dateien werden vom Filesystem in Cluster aufgeteilt. Dann werden diese Cluster nacheinander auf das Raid 5 geschrieben. Ist der Cluster so groß wie ein Stripset (Stripsize * n-1; Beispiel 16K * 5-1 = 64K),wird direkt die Parity gebildet und anschließend wird das gesamte Stripeset und die Parity überschrieben.

Ist die Clustersize (Beispiel 32K) kleiner als das Stripset (64K) muss zuerst das Stripeset, sowie die Parity, welche sich auf dem Raid befinden, eingelesen werden. Jetzt werden die alten Daten des Stripsets mit den neuen Daten, welche geschrieben werden sollen, verglichen, und die Parity wird neugebildet. Erst jetzt können die neuen Daten sowie die Parity auf das Raid5 geschrieben werden.

Resultat ist logischerweise eine starke Reduzierung der Schreibgeschwindigkeit.

Wenn man also die Chance hat, es von Anfang an richtig einzustellen, sollte man das tun. Durch einen Writecache spürt man die Reduzierung möglicherweise nicht, aber dieser hat eben auch seine Nachteile.

Hat die Partition mal mit 64KB formatiert.
Siehe Anhang was passiert ist. Leider sind die Werte auch nciht das, was man erwartet.

Im RAIDXpert habe ich schon alles durchsucht. Writeback Cache kann man da leider nicht aktivieren
Schreibcache kann man dort aktivieren. Evtl. das gleiche?

Das ist doch schonmal ein Fortschritt, aber mehr Performance wird ohne "Tricks" wie WriteBackCache nicht zu holen sein. NCQ bringt hier evlt. noch etwas bessere Atto-Werte.

Der Screenshot deines RaidXperts zeigt die Einstellungen einer einzelnen Seagate, nicht die des RaidArrays. NCQ und Schreibcache gehören hier aber definitiv an geschaltet!

Mach mal ein Screenshot von den Array-Einstellungen.

NCQ kannst du auch einschalten,
mit solchen werten muss du leider mit onboard raid rechnen,
beim ICH10r chipsatz war es noch in ordnung da hatte ich ne performance von knap 130 mb/s

Mit soetwas muss man nicht rechnen, mit dem richtigen Know-How sind sehr hohe Datenraten zu erreichen. Leider ist bei AMD mit so einer großen Stripesize nicht viel zu machen.

Hier ein Raid5 am H57 Chipsatz ohne WriteBack-Cache. (5x Samsung F3 2000GB)

Erfahrungsbericht 16 W Core i3 530 Komplettsystem @ Standard V - ForumBase

 

[andichen]

uNreL2K: Danke für die Ausführungen, so richtig nachvollziehen kann ichs leider nicht, mir fehlt irgendwie das tiefere Wissen. Eigentlich reicht es mir eigentlich auch, wenn ich weiß, wie es richtig eingestellt werden muss. Viel mehr möchte ich da eigentlich auch nicht wissen...

Habe trotzdem mal einen Test gemacht, weils mir keine Ruhe gelassen hat.. Man will ja immer das Maximum rausholen und warum soll man das nicht tun, wenn es geht, schließlich hat der Controller auch Geld gekostet. Hier also die Gegenüberstellung:

Wie man sehen kann, ist das "Standard-Raid5" bei kleineren Dateien stärker, wärend es bei der anderen Einstellung bei großen Dateien der Fall ist. Bei deinem Onboard-Raid ist ja auch zu sehen, dass sich die Leistung auch erst bei großen Dateien richtig entfalten kann. Daher muss ich hier wohl eher nach der Anwendung entscheiden. Der Server soll eher für kleinere Dateien, also Word, Excel, CAD-Daten, Bilder etc. sein. So gesehen wäre für mich doch die erstere Einstellung die geeignetere Wahl. Hinzu kommt, dass ich ohnehin nicht mehr als 200MB/s übers LAN übertragen können werde. Insofern reicht das auch so. Das muss ich auch erst noch testen, habe mir mal eine Dual-Intel-NIC besorgt...

 

[uNreL2K]

andichen, hast du den writecache aktiviert?, dann es es quasi egal wie man die stripe + clustersize einstellt, vor allem wenn es nur darum geht kleine dateien so lagern und ab und zu mal aufzurufen. das ist ja nicht gerade performancedürstend. die unterschiede sind imo sehr gering.

könntest du mal den cache ausmachen?

 

[Wildsau]

Das ist doch schonmal ein Fortschritt, aber mehr Performance wird ohne "Tricks" wie WriteBackCache nicht zu holen sein. NCQ bringt hier evlt. noch etwas bessere Atto-Werte.

Der Screenshot deines RaidXperts zeigt die Einstellungen einer einzelnen Seagate, nicht die des RaidArrays. NCQ und Schreibcache gehören hier aber definitiv an geschaltet!

Mach mal ein Screenshot von den Array-Einstellungen.

[/url]

Schraibccache und NCQ sind bei den Festplatten, welche das Raid 5 Array bilden, aktiviert.

Anbei das Raid5 Array im RAIDXpert. Unter Einstellungen lässt sich nut die Bezeichnung (Name) ändern.

Ich habe noch mal einen Atto Bench hinzugefügt. Schreibcache der Festpalletn und NCQ aktiv (wenn NCQ inaktiv, kein wirklicher Unterschied)
Partition mit 64KB Formatiert

So ganz vom Hocker hauts mich zwar nicht, aber damit kann man glaub ich arbeiten. Das wird wohl das max sein, das mit der jetzigen Hardware möglich ist..?

MfG
W!ldsau

 

[uNreL2K]

Also die Maximale Schreibrate ist doch enorm gestiegen. Bei kleinen Dateigrößen ist sie aber ziemlich gering. Lass Atto nochmal laufen. AS Bench vielleicht auch einmal, aber da nur den Sequenziellen Test.

 

[andichen]

andichen, hast du den writecache aktiviert?, dann es es quasi egal wie man die stripe + clustersize einstellt, vor allem wenn es nur darum geht kleine dateien so lagern und ab und zu mal aufzurufen. das ist ja nicht gerade performancedürstend. die unterschiede sind imo sehr gering.

könntest du mal den cache ausmachen?

Ja, da war der Schreibcache natürlich an. Es ging ja darum, ob es auch bei aktiviertem Schreibcache einen Unterschied macht. Leider äußert sich das scheinbar nur bei großen Dateien. Es ist ja doch sichtbar, dass es bei kleineren Dateien von 4-32K komischerweise weniger ist. "Performancedürstend" oder nicht, es ist doch weniger...

Soo..jetzt muss du mal wieder den Erklärbär spielen und die nächsten Attos erklären... Für mich ist das nun wieder gänzlich unverständlich...

Beides wie beim letzten Test, nur jeweils mit deaktiviertem Schreibcache. Logischerweise ist der 2. jetzt fixer, aber warum bricht die Sache ab 512K wieder ein!? Da gings ja bei dir erst richtig los... Ich glaub, dass ich schnell wieder den Schreibcache anmach...

 

[Wildsau]

Jetzt nochmal paar Ergebnisse:

Festplatte: 3x Seagate ST2000DL003 (2TB)
Controller: AMD 890GX Chipset
Raid: Raid 5
Stripe Size: 64KB
Cluster Size: 64KB

Write Test sind mit AIDA64 leider nicht möglich. Bekomm nen Fehler (Cannot open drive 'Disk Drive #3 [AMD 2+1 Disk RAID5] (3725,9GB)'

Kann man nun mit den Werten was anfenagen oder nicht? Mich verunsichert der Atto Bench, da dort die Tranfser Size bei kleinen Dateien sehr mager ausfällt.
Habe keine lust alles auf zu spielen und dann lahmt die Kiste.

Alternativ (aber halt nicht geplant) noch eine weitere Platte hohlen und ein Raid 5 mit 4 Platten oder ein Raid 10 (aber halt wieder hoher Speicherverlust)

MfG
W!ldsau

 

[BlackGhost]

Ohne Writeback-Cache beim Raid 5 sollte die Clustersize folgendem Schema entsprechen:

Stripesize * n-1

n=Anzahl der Memberdisks.

Beispiel: 5 HDDs im Raid 5
Stripesize: 16K
Clustersize: 64K

weil: 16K (Stripesize) * 5-1 (=4) ergibt 64K.

Das würde ja für ein RAID5 aus acht Festplatten (Stripe-Size: 128k) eine NTFS Cluster-Size von 896k bedeuten
Also das ist relativ weit ab von dem was ich bis jetzt gehört und gesehen haben

Woher stammen diese Werte?
Hat das auch mal ein Controller Hersteller bestätigt bzw empfohlen?

 

[Wildsau]

Das würde ja für ein RAID5 aus acht Festplatten (Stripe-Size: 128k) eine NTFS Cluster-Size von 896k bedeuten
Also das ist relativ weit ab von dem was ich bis jetzt gehört und gesehen haben

Woher stammen diese Werte?
Hat das auch mal ein Controller Hersteller bestätigt bzw empfohlen?

Wie er schreibt, ist diese Formel nur bei Raid 5 ohne Writeback-Cache anzuwenden.
Wer nun aber 8 Festplatten in einen Raid 5 betreibt, nutzt dabei auch sicherlich einen brauchbaren Controller.

Aber so ganz steig ich da auch nicht mehr durch. Vorallem was ich nun machen soll. Raid5 beibehalten oder auf Raid 10 umrüsten

MfG
W!ldsau

 

[BlackGhost]

Ich kann die Bedenken wegen Write Back durchaus verstehen .. jedoch betreiben hier viele auch an großen Controllern ihre RAID Volumes eben ohne extra teure BBU.
Von Problemen hat bis jetzt keiner berichtet.

Wie paranoid man nun auch ist .. wenn man es richtig machen will, sollte man neben der BBU auch direkt für eine USV sorgen

 

[andichen]

Wie paranoid man nun auch ist .. wenn man es richtig machen will, sollte man neben der BBU auch direkt für eine USV sorgen

Genau so habe ich das jetzt, aber ruhiger schlafen tu ich iwie trotzdem nicht... Je mehr man hat, desto mehr Sorgen hat man, scheint normal zu sein... :/

 

[Wildsau]

Ähm... um jetzt nicht ganz als Ahnungsloser da zu stehen, habe ich mal nach BBU gegoggelt. Gefunden habe ich das

Der Artikel hat mich doch etwas beunruhigt.
Also bei einen Stromausfall oder wenn die Kiste beim Schreibvorgang abschmiert, sind alle Daten weg?
Ist das nur bei Aktiven WriteCache?
Würde mich das auch betreffen?

MfG
W!ldsau

 

[BlackGhost]

Ja das betrifft jeden, der einen flüchtigen Speicher als Cache benutzt.

Das trifft aber auch auf deinen RAM und den Cache der CPU zu .. oder wo die Daten auch immer auf ihrem Weg gerade hängen.

100% Schutz gibt es nie ... aber da man eh ein Backup haben sollte, kann man entsprechend reagieren, falls trotzdem Daten mal verloren gehen sollte.

Aber nun wieder

 

[Schlingel_INV]

Ähm... um jetzt nicht ganz als Ahnungsloser da zu stehen, habe ich mal nach BBU gegoggelt. Gefunden habe ich das

Der Artikel hat mich doch etwas beunruhigt.
Also bei einen Stromausfall oder wenn die Kiste beim Schreibvorgang abschmiert, sind alle Daten weg?
Ist das nur bei Aktiven WriteCache?
Würde mich das auch betreffen?

MfG
W!ldsau

so sieht es aus. und wenn der onboard mal theoretisch 8GB ram als cache nutzt, diese voll sind und dann der strom abschmiert sind halt daten von 8GB auf dem array fricke. das ist halt der nachteil.

deshalb gibt es BBUs die den controller-cache weiter am leben halten. das behebt das problem writeback+stromausfall.

so und dann bleibt da noch der hdd-cache. auch der ist im falle von strom weg ebenfalls hin. wobeiich gelesen habe, das aktuelle hdds diesen noch irgendwie auf die platter schreiben können.

für ausreichend schutz hilft nur BBU+USV oder besser BBU+ hdd-cache off oder noch besser write-through
+hdd-cache off.

damit sind plattendefekte und inkonsistenz der daten noch gar nicht bzw immer nicht berücksichtigt