In SQL Server sind E / A-Anforderungen aufgetreten, die länger als 15 Sekunden dauern

In Production SQL Server haben wir folgende Konfiguration:

3 Dell PowerEdge R630-Server, zusammengefasst in die Verfügbarkeitsgruppe Alle 3 sind mit einer einzigen Dell SAN-Speichereinheit verbunden, die ein RAID-Array ist

Von Zeit zu Zeit sehen wir auf PRIMARY Nachrichten, die der folgenden ähneln:

SQL Server hat festgestellt, dass 11 E / A-Anforderungen länger als 15 Sekunden in der Datei [F: \ Data \ MyDatabase.mdf] in Datenbank-ID 8 ausgeführt wurden.
Das OS-Dateihandle lautet 0x0000000000001FBC.
Der Offset der letzten langen E / A lautet: 0x000004295d0000.
Die Dauer der langen E / A beträgt: 37397 ms.

Wir sind ein Anfänger in der Leistungsbehebung

Was sind die gängigsten Methoden oder Best Practices zur Fehlerbehebung bei diesem bestimmten Speicherproblem? Welche Leistungsindikatoren, Tools, Monitore, Apps usw. müssen verwendet werden, um die Hauptursache für solche Nachrichten einzugrenzen? Könnte es ein Extended Events geben, das helfen kann, oder eine Art Audit / Logging?

Wir haben eine ähnliche Konfiguration und sind kürzlich auf diese Meldungen in den Protokollen gestoßen. Wir verwenden ein DELL Compellent SAN. Im Folgenden finden Sie einige Punkte, die beim Empfang dieser Nachrichten überprüft werden müssen, damit wir eine Lösung finden können

• Überprüfen Sie die Windows-Leistungsindikatoren für Ihre Datenträger, auf die die Warnmeldungen verweisen, insbesondere:
  • Datenträger-Durchschn. Lesezeit
  • Datenträger-Durchschn. Zeit schreiben
  • Festplattenlesebytes / Sek
  • Plattenschreibbytes / Sek
  • Plattenübertragungen / Sek
  • Durchschn. Länge der Festplattenwarteschlange
• Die oben genannten sind Durchschnittswerte. Wenn Sie viele Datenbankdateien auf einem Laufwerk haben, können diese Durchschnittswerte das Ergebnis verzerren und einen Flaschenhals für bestimmte Datenbankdateien maskieren. Schauen Sie sich diese Abfrage von Paul S. Randal an, die die durchschnittliche Latenz für jede Datei vom dmv zurückgibtsys.dm_io_virtual_file_stats . In unserem Fall war die gemeldete durchschnittliche Latenz akzeptabel, aber unter den Deckblättern hatten wir viele Dateien mit einer durchschnittlichen Latenz von> 200 ms.
• Überprüfen Sie die Timings. Gibt es ein Muster? Kommt es zu einer bestimmten Zeit in der Nacht häufiger vor? Überprüfen Sie in diesem Fall, ob zu diesem Zeitpunkt Wartungsaufträge ausgeführt werden oder geplante Aktivitäten, die die Festplattenaktivität erhöhen und einen Flaschenhals in Ihrem E / A-Subsystem freilegen können.
• Überprüfen Sie die Windows-Ereignisanzeige auf Fehler. Wenn Ihr Switch oder SAN überlastet ist oder nicht richtig für Ihre Anwendung eingerichtet wurde, finden Sie möglicherweise einige Meldungen in diesem Protokoll. Es empfiehlt sich, diese Informationen an Ihren SAN-Administrator weiterzuleiten. In unserem Fall haben wir den ganzen Tag über häufig iSCSI-Verbindungsfehler erhalten, die auf das Problem hinweisen.
• Überprüfen Sie Ihren SQL Server-Code. Wenn Sie diese Nachrichten erhalten, sollten Sie nicht sofort davon ausgehen, dass es sich um ein E / A-Subsystemproblem handelt, und es an Ihren SAN-Administrator weiterleiten. Sie müssen Ihren Beitrag leisten und die Datenbank überprüfen. Haben Sie wirklich schlechte Abfragen, die oft durch Tonnen von Daten laufen? Schlechte Indizierung? Übermäßiges Schreiben von Transaktionsprotokollen? Sie können einige Open-Source-Abfragen verwenden, um eine Integritätsprüfung für Ihre Datenbank durchzuführen. Ein Beispiel für die Überprüfung Ihres Abfrageplans ist sp_blitzCache
• Ignoriere diese nicht. Heutzutage erhalten Sie sie möglicherweise einige Male am Tag ... und einige Monate später, wenn Ihre Arbeitsbelastung zunimmt und Sie vergessen haben, sie zu überwachen, nehmen sie zu. Das Empfangen vieler dieser Nachrichten kann verhindern, dass SQL Server auf eine bestimmte Datei zugreift, und wenn es sich um Tempdb handelt, ist das nicht gut. In unserem Fall wurde es so schlimm, dass SQL Server sich selbst herunterfuhr.

Unsere Lösung bestand darin, unseren Switch auf einen SAN-Switch zu aktualisieren. Ja, dies sind alles Punkte, die in SQL Server behandelt werden müssen. Als wir herausfanden, dass es sich um einen Switch handelte, erhielten wir im Windows-Anwendungsereignis-Viewer auf dem SQL Server täglich etwa 1500 iSCSI-pdu-Verbindungsfehler. Dies veranlasste die SAN-Administratoren zu einer Untersuchung des Switches.

Unmittelbar nach dem Upgrade waren die iSCSI-Fehler verschwunden und die durchschnittliche Latenz für alle Dateien betrug ca. 50 ms. Dies korrelierte mit einer besseren Leistung in der Anwendung. Unter Berücksichtigung dieser Punkte können Sie hoffentlich Ihre Lösung finden.

Dies ist weitaus seltener ein Festplattenproblem und weitaus häufiger ein Netzwerkproblem. Wissen Sie, das N in SAN?

Wenn Sie zu Ihrem SAN-Team gehen und davon sprechen, dass die Datenträger langsam sind, wird Ihnen ein ausgefallenes Diagramm mit einer Latenz von 0 Millisekunden angezeigt, und Sie werden mit einem Hefter darauf hingewiesen.

Fragen Sie sie stattdessen nach dem Netzwerkpfad zum SAN. Holen Sie sich Geschwindigkeiten, wenn es multipathed ist, etc. Holen Sie sich Zahlen von ihnen über die Geschwindigkeiten, die Sie sehen sollten. Fragen Sie, ob sie Benchmarks aus der Zeit haben, als die Server eingerichtet wurden.

Dann können Sie Crystal Disk Mark oder diskpd verwenden , um diese Geschwindigkeiten zu überprüfen . Wenn sie sich nicht wieder anstellen, ist es höchstwahrscheinlich die Vernetzung.

Sie sollten Ihr Fehlerprotokoll auch nach Nachrichten durchsuchen, die "FlushCache" und "Sättigung" enthalten, da dies auch Anzeichen für Netzwerkkonflikte sein können.

Sie können diese Dinge als DBA vermeiden, indem Sie sicherstellen, dass Ihre Wartung und andere datenintensive Aufgaben (wie ETL) nicht gleichzeitig ausgeführt werden. Das kann das Speichernetzwerk definitiv stark unter Druck setzen.

Sie können auch die Antworten hier überprüfen, um weitere Vorschläge zu erhalten: Langsamer Checkpoint und 15-Sekunden-E / A-Warnungen im Flash-Speicher

Ich habe hier über ein ähnliches Thema gebloggt: Vom Server zum SAN

Warum sollten die Daten in einem SAN gespeichert werden? Was ist der Sinn? Die gesamte Datenbankleistung ist an die Datenträger-E / A gebunden, und Sie verwenden 3 Server mit nur einem Gerät für die dahinter stehende E / A. Das macht keinen Sinn ... und ist leider so verbreitet.

Ich habe mein Leben damit verbracht, auf schlecht gestaltete Hardwareplattformen zu stoßen, auf denen die Leute nur versuchen, einen großen Computer zu entwerfen. Alle CPU-Leistung hier, alle Festplatten dort ... hoffentlich gibt es nicht so etwas wie Remote-RAM. Und das Traurigste ist, dass sie die mangelnde Effizienz dieses Designs mit riesigen Servern ausgleichen, die zehn Mal mehr kosten als sie sollten. Ich habe gesehen, dass 400.000 USD langsamer sind als ein 1.000 USD teurer Laptop.

Eine SQL Server-Software ist eine sehr fortschrittliche Software, die entwickelt wurde, um alle Teile von Hardware, CPU-Kernen, CPU-Cache, TLB, RAM, Festplattencontrollern, Festplatten-Cache usw. zu nutzen. Sie enthält fast die gesamte Dateisystemlogik. Sie werden auf normalen Computern entwickelt und auf High-End-Systemen getestet. Daher muss ein SQL Server über eigene Festplatten verfügen. Wenn Sie sie in einem SAN installieren, bedeutet dies, dass Sie einen Computer "emulieren". Dadurch verlieren Sie alle Leistungsoptimierungen. SANs dienen zum Speichern von Sicherungen, unveränderlichen Dateien und Dateien, an die Sie nur Daten anhängen (Protokolle).

Datacenter-Administratoren verwenden in der Regel alles, was sie können, für SANs, da nur ein Speicherpool verwaltet werden muss. Dies ist einfacher als die Verwaltung des Speichers auf jedem Server. Es ist eine sehr schlechte Entscheidung, "Ich möchte meinen Job nicht machen", denn dann haben sie mit Leistungsproblemen zu kämpfen und das ganze Unternehmen leidet darunter. Installieren Sie einfach die Software auf der Hardware, für die sie entwickelt wurde. Halte es einfach. Pflege der E / A-Bandbreite, Cache- und Kontextwechsel-Overhead, Ressourcen-Jitter (tritt auf, wenn Ressourcen gemeinsam genutzt werden). Sie werden am Ende 1/10 der Geräte für die gleiche Ausgangsleistung beibehalten, Ihrem OP-Team viel Kopfzerbrechen ersparen, die Leistung steigern, die Ihre Endbenutzer glücklich und produktiver macht, Ihr Unternehmen zu einem besseren Arbeitsplatz machen und viel Energie sparen (der Planet wird es Ihnen danken).

Sie sagten in Kommentaren, Sie erwägen, SSD in Ihren Server zu setzen. Sie werden Ihr Setup mit dedizierten SSDs nicht erkennen, im Vergleich zu einem SAN werden Sie sogar mit Daten- und Transaktionsprotokolldateien auf demselben Laufwerk eine etwa 500-fache Verbesserung erzielen. Ein SQL Server nach dem neuesten Stand der Technik verfügt über eine schnelle separate SSD für Daten und Transaktionsprotokolle auf verschiedenen Hardware-Controller-Kanälen (die meisten Server-Motherboards verfügen über mehrere). Aber im Vergleich zu Ihrem aktuellen Setup sprechen wir hier von Sci-Fi. Probieren Sie SSD einfach aus.

Ok, für alle Interessierten,

Wir haben das Problem in Question vor einigen Monaten einfach gelöst, indem wir direkt angeschlossene SSD-Laufwerke auf jedem der drei Server installiert und DB-Daten und -Protokolldateien von SAN auf diese SSD-Laufwerke verschoben haben

Hier eine Zusammenfassung darüber, was ich getan habe, um zu diesem Problem zu recherchieren (unter Verwendung von Empfehlungen aus allen Posts dieser Frage), bevor wir uns entschieden haben, SSD-Laufwerke zu installieren:

1) begann PerfMon-Indikatoren für folgende Laufwerke auf allen 3 Servern zu sammeln:

Disk F:Ist eine logische Festplatte, die auf SAN basiert. Enthält MDF-Datendateien. Ist eine
Disk I:logische Festplatte, die auf SAN basiert. Enthält LDF-Protokolldateien.
Disk T:Ist eine direkt angehängte SSD, die ausschließlich für tempDB bestimmt ist

Das Bild unten zeigt Durchschnittswerte, die für einen Zeitraum von 2 Wochen gesammelt wurden

Disk I: (LDF)hat so ein kleines E / A und die Latenz ist sehr gering, so dass Datenträger I: ignoriert werden
kann. Sie können sehen, dass er Disk T: (TempDB)ein größeres E / A im Vergleich zu Disk F: (MDF)und gleichzeitig eine viel bessere Latenz aufweist - 0 ms

Offensichtlich stimmt etwas nicht mit Datenträger F: Wo sich Datendateien befinden, weist er trotz niedriger E / A-Werte eine hohe Latenz und eine durchschnittliche Datenträgerschreibwarteschlange auf

2) Überprüfte Latenz für einzelne Datenbanken mit Abfrage von dieser Website

https://www.brentozar.com/blitz/slow-storage-reads-writes/

Nur wenige aktive Datenbanken auf dem Primärserver hatten eine Leselatenz von 150 bis 250 ms und eine Schreiblatenz von 150 bis 450 ms.
Interessanterweise hatten Master- und MSDB-Datenbankdateien eine Leselatenz von bis zu 90 ms. Ein weiteres Anzeichen ist, dass etwas mit SAN nicht stimmt

3) Es gab keine spezifischen Zeitpunkte

Während der Meldung "SQL Server hat Vorkommen festgestellt ..."
wurden keine Wartungs- oder plattenintensiven ETL-Vorgänge ausgeführt, als diese Meldungen protokolliert wurden

4) Windows-Ereignisanzeige

Es wurden keine anderen Einträge angezeigt, die auf das Problem hindeuten, außer "SQL Server hat Vorkommen festgestellt ...".

5) Überprüfung der 10 häufigsten Anfragen gestartet

Vom sp_BlitzCache (CPU, liest, etc.) und wenn möglich omptimieren
Keine übermäßigen E / A- Abfragen, die Unmengen von Daten verbrauchen und den Speicher stark beeinträchtigen würden, obwohl die
Indizierung in Datenbanken in Ordnung ist

6) Wir haben kein SAN-Team

Wir haben nur 1 Systemadministrator, der gelegentlich hilft.
Netzwerkpfad zu SAN - es ist multipathed, jeder von 3 Servern hat 2 Netzwerkkabel, die zu Switches und dann zu SAN führen, und es soll 1 Gigabyte / Sek. Sein

7) Es gab keine CrystalDiskMark-Ergebnisse

Oder andere Benchmark-Testergebnisse aus der Zeit, als die Server eingerichtet wurden. Daher weiß ich nicht, wie hoch die Geschwindigkeiten sein sollten, und es ist derzeit nicht möglich, einen Benchmark zu erstellen, um festzustellen, wie hoch die Geschwindigkeiten derzeit sind, da dies die Produktion beeinträchtigt hätte

8) Erweiterte Ereignissitzung für das Prüfpunktereignis für die betreffende Datenbank einrichten

Mithilfe der XE-Sitzung wurde festgestellt, dass der Checkpoint während der Meldung "SQL Server hat Vorkommen festgestellt ..." sehr langsam ablief (bis zu 90 Sekunden).

9) SQL Server-Fehlerprotokoll

Enthaltene "FlushCache" "Saturation" -Einträge
Diese sollen angezeigt werden, wenn die Checkpoint-Zeit für eine bestimmte Datenbank die Einstellungen für das Wiederherstellungsintervall überschreitet

Die Details zeigten, dass die Datenmenge, die der Checkpoint zu löschen versucht, gering ist und lange dauert. Die Gesamtgeschwindigkeit beträgt etwa 0,25 MB / s ... seltsam

10) Schließlich zeigt dieses Bild eine Tabelle zur Fehlerbehebung bei der Speicherung:

Anscheinend haben wir lediglich ein "Hardwareproblem: - Arbeiten Sie mit dem Systemadministrator / Hardwarehersteller zusammen, um etwaige Fehlkonfigurationen von SAN, alten / fehlerhaften Treibern, Controllern, Firmware usw. zu beheben."

In einer anderen Frage "Slow Checkpoint ..." Langsamer Checkpoint und 15-Sekunden-E / A-Warnungen im Flash-Speicher Sean eine sehr gute Liste, welche Elemente auf Hardware- und Softwareebene überprüft werden müssen, um Fehler zu beheben

Unser Systemadministrator konnte nicht alle Elemente aus der Liste überprüfen, daher haben wir uns einfach dafür entschieden, einige Hardwarekomponenten in dieses Problem zu werfen - es war überhaupt nicht teuer

Auflösung:

Wir haben 1 TB SSD-Laufwerke bestellt und direkt auf Servern installiert

Da Verfügbarkeitsgruppen vorhanden sind, wurden DB-Datendateien auf sekundären Replikaten von SAN auf SSD migriert, anschließend ein Failover durchgeführt und Dateien auf früheren primären Replikaten migriert. Dies ermöglichte eine minimale Gesamtausfallzeit von weniger als 1 Minute

Jetzt verfügt jeder Server über eine lokale Kopie der DB-Daten, und es werden vollständige / Diff / Log-Sicherungen im erwähnten SAN durchgeführt.
In den Windows-Ereignisanzeige-Protokollen werden keine Meldungen mehr "SQL Server ist aufgetreten ..." und keine Sicherungen, Integritätsprüfungen mehr durchgeführt. Index-Neuerstellungen, Abfragen usw. haben erheblich zugenommen

Wie viel Leistung in Bezug auf die E / A-Latenz hat sich verbessert, seit wir DB-Dateien auf SSD migriert haben?

Verwendete Windows-Leistungsüberwachungsprotokolle 2 Wochen vor der Migration und 4 Wochen nach der Migration, um die Auswirkungen zu bewerten:

Weiter unten finden Sie einen Vergleich der Latenzstatistiken auf DB-Ebene (die erfassten virtuellen Dateistatistiken von SQL Server werden vor und nach der Migration verwendet).

Zusammenfassung

Die Migration von SAN auf direkt angeschlossene lokale SSDs hat sich gelohnt
Sie hatte einen großen Einfluss auf die Latenz des Speichers und verbesserte sich im Durchschnitt um mehr als 90% (insbesondere bei WRITE-Vorgängen). Wir haben keine 20-50-Sekunden-Spitzen mehr bei IO

Die Umstellung auf eine lokale SSD behebt nicht nur Probleme mit der Speicherleistung, sondern auch mit der Datensicherheit, um die ich mir Sorgen gemacht habe (wenn das SAN ausfällt, verlieren alle drei Server gleichzeitig ihre Daten).