Performance / RaidController - Write Back oder Write Through

[wznutzer 35]

Guten Morgen,

 

routinemäßig stellte ich auf allen meinen Server im Raid-Controller immer WriteBack als Policy ein. Nun sagte mir ein Mitarbeiter von Lenovo, dass wäre falsch, für maximale Performance solle man die Policy auf WriteThrough stellen.

 

Mich würde eure Erfahrung interessieren, was bei euch mehrheitlich eher besser war? Wohlwissend, dass das auf den Workload ankommt und bei SSDs nicht mehr so den Boost als noch vor vielen Jahren bringt. Vorrangig geht es um den Betrieb von SQL-Server.

 

Im Live-Betrieb stelle ich keine Veränderung fest. Bei Tests mit DiskSPD werden tatsächlich bessere Ergebnisse mit WriteThrough ermittelt. Das aber nur wenn ich dem Controller so viel zu tun gebe, dass dessen Cache nicht mehr ausreicht und so wieder auf das Storage gewartet werden muss.  Es sieht so aus, als ob WriteBack (auch mit SSDs) etwas bringt so lange so wenig geschrieben wird, dass der Cache des Controller nicht überläuft. Ist das aber der Fall, scheint der Cache, oder der Mechanismus dahinter, den Vorgang mehr zu bremsen als wenn gleich direkt auf das Storage geschrieben wird.

 

Vielen Dank für eure Meinungen.

[NorbertFe 2.089]

Irgendwie widerspricht die Aussage dem, was ich bisher glaubte zu wissen. Write back sollte bei der Schreibperformance normalerweise schneller sein.

 

andereseits sagte ein Kollege aus der storageabteilung schon vor Jahren: Cache ist geborgte Zeit. ;)

[zahni 558]

Das hängt vermutlich auch vom verwendeten RAID-Modus und der Anzahl der Spindeln ab. Mir wurde mal erklärt, dass die Berechnung der Paritätsinformationen (u.a. RAID 5) mit Cache performanter ist.

[Dukel 457]

Fast.

Der Nachteil der Performance bei Raid 5 wird durch den Cache gemildert.

bearbeitet 18. Februar 2021 von Dukel

[djmaker 95]

Eventuell bringt der Artikel Licht dazu . . . die Aspekte habe ich bisher nicht betrachtet da ich im Prinzip keine Server mehr installiere wo lokale Daten vorgehalten werden (außer Backup-Server):

 

https://www.admin-magazine.com/Archive/2015/28/Tuning-SSD-RAID-for-optimal-performance/(offset)/6

[NorbertFe 2.089]

Ja, aber im Storageumfeld ist das Thema WriteBack/WriteThrough doch grundsätzlich ähnlich, oder täusche ich mich da?

bearbeitet 18. Februar 2021 von NorbertFe

[daabm 1.366]

vor 13 Stunden schrieb NorbertFe:

Write back sollte bei der Schreibperformance normalerweise schneller sein.

Ersetze "sollte" durch "ist". Nachteil: Du brauchst ne USV oder nen Battery Buffer auf dem Controller. Frag mich nicht, woher ich das weiß...

[NorbertFe 2.089]

Ok danke für die Bestätigung. Gibts raid Controller ohne bbu? Jeder raid Controller den ich kenne, schaltet sogar auf writethrough wenn seine Batterie leer ist. ;)

[daabm 1.366]

Schon mal von Intel Chipsatz Raid gehört? Brauchst nichts weiter dazu sagen, aber ja, sowas gibt's

[wznutzer 35]

Nun dann fasse ich das mal zusammen. Wie so oft bei Performance und SQL-Server muss man sagen:

Es kommt darauf an, es sollte schon außer man hat ein Szenario das halt anders ist. Und sowieso ist das Abfragedesign das A und O.

 

DiskSPD sagt mir ja klar, dass WriteThrough schneller schreibt, aber ob das meinen Workload simuliert weiß ich halt nicht. Ich dachte ich komme um den Akt mit dem SQL Distributed Replay herum, aber das wird wohl nichts werden. Der Controller ist da ein LSI 9361-i8.

[Sunny61 809]

vor 2 Stunden schrieb wznutzer:

Nun dann fasse ich das mal zusammen. Wie so oft bei Performance und SQL-Server muss man sagen:

Es kommt darauf an, es sollte schon außer man hat ein Szenario das halt anders ist. Und sowieso ist das Abfragedesign das A und O.

Nicht nur das Abfragedesign. Installiere das aktuellste SSMS auf dem SQL Server, nach ein paar Tagen Betrieb rufst Du das Leistungsdashboard auf. Rechtsklick auf die Instanz > Berichte > Standardberichte > Leistungsdashboard. Da findet sich weiter unten der Hinweis aus fehlende Indizes. Den Bericht nach DatenbankID sortieren und an die zuständigen Hersteller weitergeben. Die können/sollen ihre Hausaufgaben machen. ;)

 

Bei der SUSDB (DB vom WSUS) habe ich die fehlenden Indizies selbst angelegt und dabei einen für mich deutlich spürbaren Geschwindigkeitsschub bei der Aktualisierung der WSUS-Konsole festgestellt.

[Weingeist 159]

Eigentlich ist das ganz easy:

Kurzfristig viel Last mit Random-Iops (also kleine Datenblöcke) geschrieben auf ein verhältnissmässig langsames Storage-System ist die Domäne der Write-Caches. Also write-back wenn es gegen Stromausfall gesichert sein soll. Also insbesondere bei Spindeln. Die Iops werden quasi gebündelt und als Pseudo-sequentiell zusammengefasst und weggeschrieben (Gaaaaanz grob gesagt). Sobald die Blöcke im Cache des Controllers landen, geht der Commit für den erfolgreichen Write an das OS und es kann neue Daten schicken. Bei SSD's bringt es das nicht weil der commit von der Platte sowieso kommt bevor der Write tatsächlich gemacht wurde und vernünftige SSD's darin insgesamt zügiger sind als das hin und her zwischen Controller/Platte. Hier muss für einen Sicherheitsgewinn im Raid-Betrieb die SSD selbst gegen Stromausfälle gesichert sein, sonst würde auch der bestens gepufferte Write-Cache des Controllers nix helfen. Ist die Platte selbst abgesichert (Kondensatoren), bringt auch der Controller nix mehr und steht nur im Weg (grob gesagt). Der Cache bringt daher nur etwas, wenn der Zeitgewinn durch die zusammengefassten writes eine ausreichende Entlastung bringt. Bei Magnetplatten und Random-IO ist das normalerweise der Fall. Bei SSD's nicht. Deshalb ist er auch standardmässig deaktiviert auf SSD-Raid-Volumes (z.Bsp. LSI-Controller).

 

Write Back ohne gepufferten Cache = möglicher bis sicherer Datenverlust bei Stromausfall. Ausser den Platten war zufälligerweise gerade langweilig. (Egal ob durch Netzteil, System-Absturz oder  den Stromanbieter verursacht).

 

Sequentielle Workloads wie grosse Dateien kopieren: Write-Through ist immer schneller sobald der Cache voll ist. Weil der Write-Cache bringt nur zusätzlicher Overhead sobald er voll ist. Das ist  bei sequentiellen Loads ziemlich schnell der Fall. Selbst grosse SAN's haben daher sehr selten grosse Write-Caches.

 

Wenn wirklich viel Write-Performance gefragt ist und verhältnissmässig wenig Read, läuft es dann auf Tiered Storage raus oder das Subsystem selbst muss halt für Read und Write entsprechend Performant sein. Manche Storage-Systeme schreiben auch erst in RAID 10 und wandeln dann zbsp. in RAID 6 um wens ihnen langeweiliger ist.

--> Windows Storage Spaces puffert z.Bsp. nur die Random-IO's (Std bis 256KB), sequentielle Loads gehen direkt auf die Platten. Egal ob man einen riesigen Write-Cache von X-GB zu Verfügung hätte.

bearbeitet 22. Februar 2021 von Weingeist

[Sunny61 809]

Hier nochmal der Thread ins Technet Forum, in dem ein fast fertiges Script gepostet wurde: https://social.technet.microsoft.com/Forums/lync/en-US/2393a40f-cea8-4bfa-ab72-42b8eaebe5a4/overcoming-the-slow-wsus-clean-up?forum=winserverwsus