In dieser Fortsetzung meiner Serie zur Leistungsoptimierung möchte ich auf Solid State Disks (SSDs) und einige der Probleme eingehen, die ich bei ihrer Verwendung in einer SQL Server-Umgebung sehe. Eine ausführliche Beschreibung von SSDs finden Sie in diesem Wikipedia-Artikel.
Was leisten SSDs für die Leistung von SQL Server?
SSDs haben keine beweglichen Teile, sodass es beim Lesen oder Schreiben fast keine E/A-Latenz gibt. Die Latenz in einem sich drehenden Laufwerk ergibt sich aus zwei Dingen:
- Bewegen des Plattenkopfs zur richtigen Spur auf der Plattenoberfläche (bekannt als Suchzeit)
- Warten, bis sich die Festplatte zum richtigen Punkt auf der Spur dreht (bekannt als Rotationslatenz)
Das bedeutet, dass SSDs bei einem E/A-Engpass einen großen Leistungsschub bieten.
So einfach ist das.
Es gibt ein paar Komplikationen, die es wert sind, erwähnt zu werden, aber den Rahmen dieses Artikels sprengen würden, um in die Tiefe zu gehen:Die SSD-Leistung kann nachlassen, wenn das Laufwerk wirklich voll wird (in diesem Artikel von AnandTech ausführlich untersucht und erklärt). Möglicherweise ist auch etwas Systemspeicher erforderlich, damit der SSD-Treiber beim Wear Leveling hilft (Verlängerung der Lebensdauer der NAND-Zellen in der SSD), und das wird je nach Anbieter variieren. Genug davon – zurück zum SQL-Server-Zeug.
Vermeiden Sie schlechte Internetberatung
Es gibt zwei sehr schlechte Ratschläge, die ich im Internet in Bezug auf SQL Server und SSDs sehe.
Der erste betrifft die Frage, was auf der SSD installiert werden soll, wobei der Rat lautet, tempdb und Ihre Transaktionsprotokolle immer auf SSDs zu speichern. Auf den ersten Blick klingt das nach einem guten Rat, da Transaktionsprotokolle und tempdb häufig Engpässe im System sind.
Aber was, wenn sie es nicht sind?
Ihre Arbeitslast wird möglicherweise hauptsächlich gelesen, in diesem Fall ist das Transaktionsprotokoll wahrscheinlich kein Engpass bei der Arbeitslast, und daher kann es eine Verschwendung einer teuren SSD sein, es auf eine SSD zu legen.
Ihre tempdb wird möglicherweise nicht sehr viel verwendet von Ihrer Arbeitslast, daher kann es eine Verschwendung einer teuren SSD sein, sie auf eine SSD zu setzen.
Wenn Sie überlegen, welcher Teil der SQL Server-Umgebung auf die SSD verschoben werden soll, sollten Sie untersuchen, wo die E/A-Engpässe liegen. Dies kann sehr einfach mit dem Code erfolgen, den ich letzte Woche gepostet habe und der die DMV sys.dm_io_virtual_file_stats verwendet, um eine Momentaufnahme der E/A-Latenzen für alle Dateien in allen Datenbanken auf der Instanz bereitzustellen. Um Ihre Latenzzahlen zu verstehen und sie mit guten/schlechten Werten zu vergleichen, lesen Sie diesen langen Beitrag, den ich speziell zu I/O-Latenzen von tempdb und Transaktionsprotokollen verfasst habe.
Und selbst wenn Sie hohe Latenzen haben, denken Sie nicht reflexartig, dass die einzige Lösung darin besteht, die schlecht funktionierende(n) Datei(en) auf eine SSD zu verschieben:
- Untersuchen Sie bei Leselatenzen von Datendateien, warum so viele Lesevorgänge auftreten. Ich behandle das hier.
- Berücksichtigen Sie bei Schreiblatenzen in Protokolldateien alle Möglichkeiten zur Optimierung der Leistung des Protokolls und dessen, was protokolliert wird. Ich behandle das hier, hier und hier.
Der schlimmstmögliche Fall ist, dass Sie eine Reihe von SSDs erhalten, den Internetratschlägen folgen, um tempdb und Ihre Protokolldateien dorthin zu verschieben, und dann gibt es keinen Leistungsgewinn bei der Arbeitslast. Das wird Ihr Management nicht dazu ermutigen, Ihnen teurere SSDs zur Verfügung zu stellen.
Der zweite schlechte Rat betrifft die Indexfragmentierung, wobei der Rat lautet, dass Sie sich bei der Verwendung von SSDs keine Gedanken über die Indexfragmentierung machen müssen, da SSDs so schnell sind.
Was für ein Unsinn!
Es gibt drei Möglichkeiten, wie ich diesen schlechten Rat widerlegen kann:
- SSDs beseitigen in keiner Weise die Ursache der Indexfragmentierung:Seitenteilungen von Seiten, die freien Speicherplatz für eine zufällige Einfügung oder eine Erhöhung der Zeilengröße benötigen. Eine Seitenaufteilung generiert die gleiche Menge an Transaktionsprotokoll, Ressourcenverbrauch und potenziellen Thread-Wartezeiten, unabhängig davon, wo die Daten/Protokolldateien gespeichert sind.
- Zur Indexfragmentierung gehören viele Daten-/Indexseiten mit geringer Seitendichte (d. h. viel leerer, freier Speicherplatz). Möchten Sie wirklich, dass Ihre teuren SSDs viel leeren Speicherplatz speichern? SSDs helfen hier überhaupt nicht weiter.
- Mein Kollege Jonathan Kehayias führte mithilfe von Extended Events eine eingehende Untersuchung von I/O-Mustern rund um die Indexfragmentierung durch, um speziell diesen schlechten Rat anzugehen, und stellte fest, dass die Indexfragmentierung bei der Verwendung von SSDs immer noch zu Leistungseinbußen führt. Du kannst seinen langen Beitrag hier lesen.
Das Einzige, was SSDs im Zusammenhang mit der Indexfragmentierung tun, ist, die Lesevorgänge zu beschleunigen, sodass es weniger Leistungseinbußen für Indexbereichsscans gibt, wenn eine Indexfragmentierung vorhanden ist, aber Punkt 3 oben zeigt, dass es immer noch einen Nachteil gibt.
SSDs ändern nicht, wie Sie mit der Indexfragmentierung in Ihrer SQL Server-Umgebung umgehen und/oder diese verhindern.
Stellen Sie sicher, dass Ihre Daten geschützt sind
Eine der Hauptsünden, die ich sehe, wenn Leute SSDs verwenden, ist, nur eine davon zu verwenden. Mit nur einem Laufwerk, welches RAID-Level verwenden Sie? Null. RAID-0 bietet überhaupt keine Redundanz.
Wenn Sie eine SSD verwenden, müssen Sie mindestens zwei in einer RAID-1-Konfiguration (Spiegelung) verwenden. Es macht keinen Sinn, eine Leistungssteigerung zu erzielen, wenn Sie dafür die Verfügbarkeit des Systems opfern.
Ein Nachteil, den ich manchmal bei der Verwendung von mindestens zwei SSDs bekomme, ist, dass die SSD-Karte zwei Laufwerke für Windows bereitstellt, und das Erstellen eines gespiegelten Windows-Volumes über die beiden Laufwerke ist also sicherlich dasselbe wie RAID-1 über zwei physisch getrennte SSDs?
Nein, ist es nicht. Es ist immer noch eine physische SSD ohne Redundanz. Haben Sie schon einmal gesehen, wie die Hälfte einer SSD-Karte ausgefallen ist? Nein, ich auch nicht. Machen Sie es richtig und verwenden Sie zwei davon und erhalten Sie echte Redundanz für Ihre Daten.
Der andere Rückschlag, den ich bekomme, ist, dass es sich um SSDs handelt, nicht um sich drehende Laufwerke, also werden sie nicht versagen. Das ist falsch. SSDs können genau wie sich drehende Laufwerke ausfallen und tun dies auch. Ich habe persönlich gesehen, wie zwei SSDs der Enterprise-Klasse beim Testen in unserer Laborumgebung versagten. Laut diesem Artikel auf StorageReview.com haben Consumer-SSDs eine MTBF von 2 Millionen Stunden im Vergleich zu 1,5 Millionen Stunden für Spinning-Laufwerke der Consumer-Klasse, und ich würde ähnliche Ergebnisse für Laufwerke der Enterprise-Klasse erwarten, aber SSDs versagen.
Zusammenfassung
Gehen Sie nicht in die Falle zu glauben, dass Sie mit allem, was Sie auf die SSD legen, eine Leistungssteigerung erhalten – Sie müssen sorgfältig auswählen. Und glauben Sie auch nicht den Unsinn da draußen über das Ignorieren der Indexfragmentierung bei der Verwendung von SSDs.
SSDs sind eine sehr nützliche Möglichkeit, die Leistung zu steigern, aber für ihre Kosten möchten Sie sicherstellen, dass Sie die Rentabilität der Investition Ihres Unternehmens maximieren, indem Sie sie richtig und nur dort einsetzen, wo es angemessen ist.
Im nächsten Artikel der Serie werde ich auf eine weitere häufige Ursache für ruckartiges Leistungstuning eingehen. Bis dahin viel Spaß bei der Fehlersuche!
