Jump to content

Performance / RaidController - Write Back oder Write Through


Recommended Posts

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.

Link to post

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. ;)

Link to post

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.

Link to post
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ß...

Link to post

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

:handrechts: 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.

Link to post
vor 2 Stunden schrieb wznutzer:

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

:handrechts: 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.

Link to post

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.

Edited by Weingeist
  • Thanks 1
Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...