Jump to content

Performance / RaidController - Write Back oder Write Through


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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 zu diesem Kommentar

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 zu diesem Kommentar
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 zu diesem Kommentar

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 von Weingeist
Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...