it-swarm.com.de

Langsamer Checkpoint und 15 Sekunden E / A-Warnungen im Flash-Speicher

In den letzten Wochen haben wir daran gearbeitet, die Ursache für das Auftreten dieser E/A-Probleme und die Verlangsamung der Prüfpunkte zu ermitteln.

Auf den ersten Blick scheint es sich eindeutig um einen E/A-Subsystemfehler zu handeln, und der SAN Administrator wurde dafür verantwortlich gemacht. Aber kürzlich haben wir das SAN in) geändert Verwenden Sie Full Flash, aber bis heute tritt der Fehler immer noch auf, und ich habe keine Ahnung, warum seit jeder Metrik, ob Wartestatistik oder einer anderen Metrik, die ich ausführe, um zu überprüfen, ob SQL Server ein möglicher Schuldiger ist, normal zurückzukehren scheint.

Das passt nicht wirklich zusammen. Es könnte auch sehr wahrscheinlich sein, dass etwas anderes auf der Festplatte kaut und SQL Server hier zum Opfer fällt ... aber ich kann nicht herausfinden, was?

DBS befinden sich in Verfügbarkeitsgruppen. Wenn diese Ereignisse auftreten, treten Rollenwechsel und Flip-Over zusammen mit Zeitüberschreitungen auf.

Jede Hilfe, um dies herauszufinden, wäre sehr dankbar. Lassen Sie mich wissen, wenn weitere Details benötigt werden.

Fehlermeldungen. unten

In SQL Server sind 14212 E/A-Anforderungen aufgetreten, deren Ausführung in der Datei [E:\MSSQL\DATA\ABC.mdf] in der Datenbank [ABC] (7) länger als 15 Sekunden dauert. Das Betriebssystem-Dateihandle lautet 0x0000000000000D64. Der Offset der letzten langen E/A beträgt: 0x0000641262c000

In SQL Server sind 5347 E/A-Anforderungen aufgetreten, deren Ausführung in der Datei [E:\MSSQL\DATA\XYZ.mdf] in der Datenbank [XYZ] (7) länger als 15 Sekunden dauert. Das Betriebssystem-Dateihandle lautet 0x0000000000000D64. Der Offset der letzten langen E/A beträgt: 0x0000506c060000

FlushCache: 111476 Bufs mit 62224 Schreibvorgängen in 925084 ms bereinigt (19 neue Dirty Bufs vermieden) für DB 7: 0 durchschnittlicher Durchsatz: 0,94 MB/s, E/A-Sättigung: 55144, Kontextschalter 98407 letztes ausstehendes Ziel: 10240, avgWriteLatency 14171 FlushCache: 5616 Bufs mit 3126 Schreibvorgängen in 248687 ms bereinigt (3626 neue Dirty Bufs vermieden) für db 6: 0 durchschnittlicher Durchsatz: 0,18 MB/s, E/A-Sättigung: 10080, Kontextwechsel 20913 letztes ausstehendes Ziel: 2, avgWriteLatency 3

Hier sind die Informationen zu den Statistiken der virtuellen Datei über einen Zeitraum von 30 Minuten:

(enter image description here

Und warten Sie auch Statistiken:

(enter image description here

Hier ist der Hinweis des Systemarchitekten:

Wir trennen Workloads für hohe E/A-intensive Workloads (z. B. DB), sodass wir nur einen pro Host haben. Die technischen Daten für den aktuellen Host sind Dell R730 mit 16 Kernen Xeon E5-2620 (2 Sockel), 512 GB und 2x10G-Verbindungen für die Speicherung. Bei keinem anderen VM auf dem Cluster oder Host treten diese Probleme auf. Der Speicher für VMs und Workloads befindet sich auf Pure FA-x20.

Allgemeine Systeminformationen:

  • SQL Server 2012 sp3-cu9 (Enterprise Edition)
  • Gesamtspeicher: 128 GB
  • Gesamt-DB-Größe: Nahezu 1 TB
6
Feivel

In den letzten Wochen haben wir daran gearbeitet, die Ursache für das Auftreten dieser E/A-Probleme und die Verlangsamung der Prüfpunkte zu ermitteln.

Hört sich gut an. Haben Sie die Minifilter- und Storport-Rückverfolgung schon gesammelt und zerschnitten? Wenn ja, was hat es gezeigt?

Auf den ersten Blick scheint es sich eindeutig um einen E/A-Subsystemfehler zu handeln, und der SAN Administrator wurde dafür verantwortlich gemacht. Aber kürzlich haben wir das SAN in) geändert Verwenden Sie Full Flash, aber bis heute tritt der Fehler immer noch auf, und ich habe keine Ahnung, warum seit jeder Metrik, ob Wartestatistik oder einer anderen Metrik, die ich ausführe, um zu überprüfen, ob SQL Server ein möglicher Schuldiger ist, normal zurückzukehren scheint.

Ich möchte hier zwei verschiedene Bereiche durchgehen.

Der erste ist, dass SQL Server selbst eigentlich nichts mit E/A macht, sondern es unter Verwendung der typischen Windows-APIs an Windows sendet. Ob es sich um ReadFile, WriteFile oder die vektorisierten E/A handelt, alles hängt von Windows ab. SQL Server führt eine Liste ausstehender E/A und überprüft diese E/A zu verschiedenen Zeiten, um den Status zu erhalten, wenn er nicht abgeschlossen ist. Dies erfolgt wiederum mit dem typischen asynchronen Windows-E/A-Modell. Die Nachricht wird gedruckt, wenn die E/A laut Windows länger als 15 Sekunden aussteht und nicht abgeschlossen wurde, da wir die GetOverlappedResult-Windows-API verwenden, um den Status zu überprüfen. Dies bedeutet, dass SQL Server in dieser Angelegenheit nicht wirklich mitbestimmt, sondern über Windows zurückgegeben wird.

Der zweite Punkt ist, dass nur weil alles Flash und 10-GB-Glasfaser ist, nicht bedeutet, dass etwas nicht falsch eingerichtet oder konfiguriert ist, dass ein Treiber, Filter oder ein anderer Fehler oder Gegenstand nicht getroffen wird oder dass etwas nicht physisch ist falsch. Nur um eine Idee zu bekommen:

  1. Windows-Konfiguration
  2. Windows-Treiber wie das Einrichten von Mehrfachpfaden und die neueste Version
  3. Filtertreiber (Sie wissen, Festplattengeräte, Antivirenprogramme, Backups usw.)
  4. Hypervisoren (falls vorhanden)
  5. HBA-Treiber
  6. HBA-Firmware
  7. HBA-Konfiguration
  8. Physische Verkabelung
  9. Faserumschaltung
  10. E/A-Gruppenverbindungen/SAN/Gerät
  11. Konfiguration von SAN/Gerät

Das ist alles unter SQL Server, es ist nur so, dass SQL Server derjenige ist, der erzählt Sie darüber.

DBS befinden sich in Verfügbarkeitsgruppen. Wenn diese Ereignisse auftreten, treten Rollenwechsel und Flip-Over zusammen mit Zeitüberschreitungen auf.

Das sind wirklich gute Informationen, obwohl es nicht unbedingt bedeutet, dass sie genau miteinander zusammenhängen. Wenn es nur bei einem Failover passiert, würde sich das Problem erheblich verbessern, und das würde sich für mich eher nach den Treibern et al. Anhören. mag es nicht, eine ganze Menge gemischter E/A darauf zu werfen, da ein Failover normalerweise zu einem Wiederherstellen/Rückgängigmachen und einer erneuten Synchronisierung führt, was zu einem Anstieg der herausragenden E/A führen kann.

Jede Hilfe, um dies herauszufinden, wäre sehr dankbar.

Es sei denn, es handelt sich um eine Abfrage oder eine Reihe von Abfragen, die hohe IOPs auslösen. Dies klingt nicht so, als ob der Snapshot für 30 Minuten nur 737.465 E/A-Vorgänge waren, die im Durchschnitt bis 410 IOPs (nicht so hoch, besonders wenn es sich um Flash handelt), die in SQL Server hineinschauen, helfen bei diesem Problem nicht, da SQL Server der Messenger ist.

Sie möchten sammeln, wenn nicht bereits:

  1. Minifilterzeit verbracht. Dies kann über WPR (XPerf) erfolgen, wenn Sie nichts anderes haben. Dies kann hilfreich sein, wenn die E/A in einem Filtertreiber blockiert wird.
  2. Storport-Spur. Dies ist die letzte Station auf dem Weg und die erste Station auf dem Rückweg. Jede Zeit zwischen diesen beiden Messwerten ist Zeit, die außerhalb von Windows verbracht wird. Außerdem werden Ihnen die Ziele und die Position der Langsamkeit am anderen Ende angezeigt (dies ist jedoch nicht immer schlüssig).

Wenn keines dieser Elemente bei der Diagnose hilfreich ist oder den Umfang des Problems einschränkt, ist es möglicherweise an der Zeit, ein Ticket mit Windows Storage-Unterstützung zu öffnen und alle Daten bereits zu erfassen, damit Sie alle auf derselben Seite beginnen können.

7
Sean Gallardy

Sie haben erwähnt, dass Sie Wartestatistiken und "jede andere Metrik" überprüfen. Ich nehme an, Sie sehen hohe PAGELATCH und WRITELOG warten? Haben Sie sys.dm_io_virtual_file_stats Zur Überprüfung überprüft? Hier würde ich anfangen, wenn ich diese 15-Sekunden-E/A-Nachrichten erhalte.

Verwenden Sie Erin Stellatos hervorragenden Artikel " Was virtuelle Dateistatistiken über die E/A-Latenz tun und was nicht " als Leitfaden für die zu verwendenden Abfragen. Protokollieren Sie alle 5 oder 15 Minuten Schnappschüsse dieser DMV in einer Tabelle. Suchen Sie nach Spitzen bei durchschnittlicher Verzögerung/Latenz.

Überprüfen Sie, ob die Anzahl der Lese-/Schreibvorgänge oder die durchschnittlichen Bytes pro Lese-/Schreibvorgang während dieser Spitzen gestiegen sind. Möglicherweise haben Sie Wartungs- oder Benutzerabfragen, die das E/A-Subsystem mit mehr Datenverkehr überfluten, als es verarbeiten kann. Diese Abfragen müssen optimiert werden, oder die Wartungsaufgaben müssen aufgeteilt oder auf eine andere Tageszeit verschoben werden.

Arbeiten Sie mit Ihrem SAN Administrator) zusammen, um festzustellen, ob "laute Nachbarn" oder Fehler im SAN, die mit diesen Zeiten korrelieren) vorhanden sind. Vergleichen Sie die SAN Setup mit anderen SQL Server-Boxen - Möglicherweise liegt ein Durchsatzproblem auf der Ebene der physischen Verbindung vor, oder Sie haben Caching-Einstellungen, die angepasst werden müssen oder Aktualisierungen, die vorgenommen werden müssen installiert usw.

Mir ist klar, dass dies etwas allgemeine Schritte sind, aber hoffentlich gibt es Ihnen eine Richtung, wohin Sie als nächstes gehen sollen.

Was das betrifft:

Wir trennen Workloads für Workloads mit hoher E/A-Intensität (z. B. DB), sodass wir nur einen pro Host haben ... Bei keinem anderen VM auf dem Cluster oder Host treten diese Probleme auf

Ich denke, es ist sinnvoll, dass SQL Server der einzige ist, der diese Probleme sieht, wenn es der einzige mit einer hohen E/A-Arbeitslast auf dem Host ist - die anderen Server/Anwendungen bemerken dies möglicherweise nicht einmal oder haben keine Möglichkeit, dies zu melden Festplattenlatenz.

Das E-Laufwerk sieht in Ihrem Screenshot der Statistiken der virtuellen Dateien besonders problematisch aus. Gibt es etwas anderes an diesem Laufwerk?

... 2x10G-Verbindungen zur Speicherung

Möglicherweise liegt ein Verkabelungsproblem vor. Ziehen Sie in Betracht, sie erneut einzusetzen/sicherzustellen, dass sie eine feste Verbindung haben. Möglicherweise mit anderen, bekanntermaßen guten Kabeln tauschen. Lassen Sie das Team SAN] die Caching-Einstellungen und andere Konfigurationen überprüfen, um festzustellen, ob es Unterschiede zwischen diesem Volume/Host und anderen SQL Server-VMs gibt.

5
Josh Darnell