Linux-Software raid10, identische Maschinen, völlig unterschiedliche Ergebnisse

Ich habe wild unterschiedliche Leistung und Verhalten von Software-Raid10 auf zwei ansonsten identischen Maschinen.

Ich habe zwei Maschinen mit identischer Hardware, die zur gleichen Zeit mit den gleichen Software-, Hardware- und Firmware-Versionen gekauft wurden. Jeder verfügt über einen SAS-Controller mit 8 x 6 Gbit / s-Kanälen, der zu einem SAS-Gehäuse mit 12 SAS-Festplatten führt.

Auf Maschine 1, die stabil ist und anscheinend einwandfrei funktioniert, verhält sich jede Festplatte im RAID-Array mehr oder weniger identisch: Die ausgelastete Zeit ist gleich (ungefähr 33% auf allen Festplatten in Produktionslaststufen), und während der wöchentlichen Software-RAID-Prüfung Läuft, Schreiben und Lesen Leistung wird nicht beeinträchtigt. Der vollständige Raid-Check ist in ungefähr einem Tag abgeschlossen und nutzt die gesamte verfügbare freie Bandbreite, um ihn so schnell wie möglich abzuschließen. Dies entspricht etwa 200 MB / Sek. Lesevorgängen, während diese Prüfung abgeschlossen ist.

Maschine 2 ist ein Problemkind. Die vollständige RAID-Prüfung wird im Grunde genommen nie abgeschlossen, obwohl sie so konfiguriert ist, dass auch die gesamte verfügbare Festplattenbandbreite verwendet wird. Während es versucht zu überprüfen, schreitet es mit 5 MB / s voran und die Schreibleistung sinkt in dieser Zeit auf ca. 30 MB / s. Außerdem sind vier Festplatten zu 35% ausgelastet, während die übrigen durchschnittlich zu 22% ausgelastet sind.

Nach Abbruch der Raid-Prüfung auf Maschine 2 kehrt die Schreibgeschwindigkeit auf ca. 160 MB / s zurück.

Wenn ich ddjedes einzelne mpathGerät teste, erhalte ich auf Maschine 1 die meisten Lesegeschwindigkeiten von 145 MB / s pro Laufwerk und die niedrigste von 119 MB / s, gefolgt von 127 MB. Der Rest liegt im Bereich von 145 MB / s.

Auf Maschine 2 erhalte ich Geschwindigkeiten zwischen 107 MB (x 3 Festplatten) und der Rest liegt über 135 MB / Sek., Wobei der Spitzenwert bei 191 MB / Sek. (!) Für eine Festplatte liegt.

Ich gebe zu, dass ich mich hier außerhalb meiner Komfortzone befinde, aber ich kann keine Beweise finden, aus denen ich eine Schlussfolgerung ziehen kann. Ich habe auch die SMART-Statistiken auf jeder Festplatte auf beiden Rechnern überprüft, und obwohl es auf allen Festplatten eine ganze Reihe von "lesekorrigierten" Fehlern gibt, scheint es keine Korrelation zwischen den Werten und der Leseleistung zu geben, noch zwischen der prozentualen Belegtdifferenz .

Nichts, was ich finden kann, erklärt die schlechte Leistung beim Durchführen einer RAID-Überprüfung des Arrays auf einer Box gegenüber der anderen. Vorschläge, wohin man als nächstes gehen soll, um dies zu debuggen, wären willkommen.

Ich habe das Problem gefunden. Der Schreibcache wurde auf 4 der 12 Festplatten im Software-Array deaktiviert.

Folgendes habe ich getan, um dies einzugrenzen:

Ich zerlegte das Array und verwendete dd mit oflag = direct, um die Schreibgeschwindigkeit auf jede Festplatte zu testen. Ich fand, dass diejenigen mit dem höheren Beschäftigungsgrad auch diejenigen waren, die nur etwa 75 MB / s schreiben konnten, während alle anderen 180 MB / s für ein dauerhaftes Schreiben mit 1 GB und 10 GB Datengröße tun konnten.

Da die 4 langsamen Festplatten jedoch alle sehr konsistent waren, fing ich sdparman, mich zu vertiefen , und installierte sie , damit ich mit den SCSI-Parameterseiten experimentieren konnte.

Als ich sah, dass die Standardeinstellung für WCE (Write Cache Enable) aktiviert ist, diese vier Datenträger jedoch deaktiviert waren, habe ich sie aktiviert. Die Schreibgeschwindigkeit stieg auf 180 MB / Sek. Und das Array wird jetzt mit einer Geschwindigkeit von 1 GB / Sek. Wiederhergestellt (was ungefähr der Höchstgeschwindigkeit entspricht, die dieser Festplattensatz mit diesem Controller verträgt.)

Der Befehl check ist sdparm --get=WCE /dev/mapper/mpathaund setzt ihn sdparm --set=WCE --save /dev/mapper/mpathafür zukünftige Benutzer.

Darüber hinaus wurde die Stromersparnis aktiviert - dies verhinderte das Zwischenspeichern auf Betriebssystemebene, um die Geschwindigkeit beizubehalten, obwohl oflag = direct dies noch tat.