Hohe IO Auslastung beim Schreiben nach Reboot von OpenMediaVault

Als zuverlässigen Speicher größerer Datenmengen setze ich OpenMediaVault ein, eine auf Debian GNU/Linux basierende NAS-Distribution. Abgesehen von den Festplatten und dem Gehäuse kommt recht alte Hardware zum Einsatz, nämlich eine AMD E-350 APU mit 1,6 GHz und 4GB DDR3 RAM. Begonnen habe ich mit 3 WD Festplatten mit je 4 TB (WD40EZRZ) in einem RAID5, inzwischen sind es 5 Festplatten. Das Erweitern des Raid Arrays war dank OpenMediaVault sehr einfach, primär nutze ich NFS und bin abgesehen von einer Sache enorm zufrieden.

Das System läuft nicht permanent, ich nutze ein kleines Script, um es bei Nichtgebrauch herunterzufahren. Ich muss zugeben, dass ich kein RAID-Experte bin. Ich weiß wie bzw. wo Daten und Paritäten gespeichert werden, wie ich es erweitere und bei Bedarf eine defekte Festplatte tauschen kann. Mir ist auch bekannt, dass die langsame CPU den Flaschenhals bildet, da das Berechnen der Paritäten recht aufwendig ist. Aber wenn ich nach dem Hochfahren eine größere Datenmenge auf das RAID5 schreibe, hängt das System für mehrere Minuten beinahe vollständig. Nach ein paar Minuten kann ich problemlos mit recht hoeher Geschwindigeit Daten schreiben.

Folgendes Beispiel veranschaulicht das Verhalten:

Die Load geht bis etwa 10 hoch, top zeigt einen hohe iowait:

Natürlich verursacht das Schreiben eine hohe IO-Aktivität und auch das flush-Prinzip ist mir bekannt, denn auf Linux Systemen werden Daten häufig asynchron erst in dem RAM und dann auf die Festplatten geschrieben, um eine möglichst hohe Performance zu gewährleisten. Wirklich stutzig macht mich hier aber die Tatsache, dass flush Daten liest. Das Resultat ist eine scheinbar schlechte Schreibperformance:

Der zweite und jede weitere Schreibvorgang hingegen läuft deutlich schneller:

167 MB/s sind für diese schwache CPU in meinem Augen völlig zufriedenstellend. Die Lesegeschwindigkeit ist ebenfalls in Ordnung:

Ein Graph der Arbeitsspeicherauslastung (auch manuell mit free -m  verfolgbar) untermauert meine Vermutung:

Der hellblaue Bereich ist der Cache, der nach dem Booten (etwa gegen 18:30 Uhr) kaum verwendet wird. Ab etwa 18:47 Uhr wächst der hellblaue Bereich, bis er ein paar Minuten später (18:55 Uhr) sprunghaft ansteigt und um 18:56 Uhr sein Maximum erreicht hat. Innerhalb dieses Zeitraums wird ebenfalls der Buffer beansprucht, der dann wieder kleiner wird, da Daten dann auf die Festplatte geschrieben werden können. Danach läuft alles wieder normal und es können ohne spürbare Performance-Engpässe Daten geschrieben werden.

Ich frage mich, was genau der flush-Prozess während des Schreibens liest und warum das Schreiben dadurch so enorm blockiert wird. Wahrscheinlich ist dies ein recht normales Verhalten, welches aber kaum auffällt, da die meisten NAS Systeme über mehr Leistung verfügen und nur selten neu gestartet werden. Aber vielleicht liegt tatsächlich ein Problem vor und ich sehe es nur nicht.

Welche Art von Daten benötigt Linux im RAM, bevor es performant schreiben kann und wie lässt sich dieser Prozess optimieren? An diesem Punkt stelle ich leider wieder einmal fest, dass mein Wissen nicht ausreicht und ich noch einiges vor mir habe. Auch das Verändern der stripe_cache_size (aktuell 8192, auch kleinere Werte bis 256 habe ich probiert) bringt bei diesem Problem keine Veränderung. Früher oder später wird sich aber eine Lösung oder zumindest eine Erklärung finden lassen. Was mich aber wundert: Hat sonst noch nie jemand dieses Verhalten in dieser Größenordnung festgestellt?

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.