it-swarm.com.de

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

Auf Production SQL Server haben wir folgende Konfiguration:

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

Von Zeit zu Zeit sehen wir auf PRIMARY ähnliche Nachrichten wie unten:

In SQL Server sind 11 E/A-Anforderungen aufgetreten, deren Ausführung in Datei [F:\Data\MyDatabase.mdf] in Datenbank-ID 8 länger als 15 Sekunden dauert.
Das Handle der Betriebssystemdatei lautet 0x0000000000001FBC.
Der Offset der letzten langen E/A beträgt: 0x000004295d0000.
Die Dauer der langen E/A beträgt: 37397 ms.

Wir sind Anfänger in der Fehlerbehebung bei der Leistung

Was sind die häufigsten Methoden oder Best Practices zur Fehlerbehebung bei diesem speziellen Problem im Zusammenhang mit der Speicherung? Welche Leistungsindikatoren, Tools, Monitore, Apps usw. müssen verwendet werden, um die Hauptursache solcher Nachrichten einzugrenzen? Könnte es ein erweitertes Ereignis geben, das helfen kann, oder eine Art Audit/Protokollierung?

16
Aleksey Vitsko

Wir haben ein ähnliches Setup und sind kürzlich auf diese Meldungen in den Protokollen gestoßen. Wir verwenden ein Dell Compellent SAN. Im Folgenden finden Sie einige Dinge, die Sie beim Empfang dieser Nachrichten überprüfen sollten, um eine Lösung zu finden

  • Überprüfen Sie Ihre Windows-Leistungsindikatoren auf Ihre Festplatten, auf die die Warnmeldungen verweisen, insbesondere:
    • Durchschn. Lesezeit
    • Durchschn. Schreibzeit
    • Festplattenlesebytes/Sek
    • Schreibbytes/Sek
    • Datenträgerü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. Check out this Abfrage von Paul S. Randal, die die durchschnittliche Latenz für jede Datei aus dem dmv sys.dm_io_virtual_file_stats Zurückgibt. In unserem Fall war die gemeldete durchschnittliche Latenz akzeptabel, aber unter der Abdeckung 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 Wartungsarbeiten ausgeführt werden oder ob geplante Aktivitäten die Festplattenaktivität erhöhen und einen Flaschenhals in Ihrem IO Subsystem freigeben können.
  • Überprüfen Sie die Windows-Ereignisanzeige auf Fehler. Wenn Ihr Switch oder SAN überlastet oder für Ihre Anwendung nicht ordnungsgemäß eingerichtet ist, 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, was auf das Problem hinweist.
  • Überprüfen Sie Ihren SQL Server-Code. Wenn Sie diese Nachrichten erhalten, sollten Sie nicht sofort glauben, dass es sich um ein IO Subsystemproblem handelt, und es an Ihren SAN Administrator weitergeben. Sie müssen Ihren Beitrag leisten und die Datenbank überprüfen. Haben Sie wirklich schlechte Abfragen, die häufig 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 des Aussehens Ihres Abfrageplans ist sp_blitzCache
  • Ignorieren Sie diese nicht. Heute 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. Wenn es sich um tempdb handelt, ist dies 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. Was uns zu dem Ergebnis führte, war, dass wir täglich etwa 1500 iSCSI pdu-Trennungsfehler in der Windows-Anwendungsereignisanzeige auf dem SQL Server erhielten. Dies veranlasste unsere SAN Administratoren zur Untersuchung des Schalters.

Unmittelbar nach dem Upgrade waren die iSCSI-Fehler behoben 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.

15
kevinnwhat

Dies ist weitaus seltener ein Festplattenproblem und weitaus häufiger ein Netzwerkproblem. Weißt du, das N in SAN?

Wenn Sie zu Ihrem SAN -Team) gehen und anfangen, über die langsamen Festplatten zu sprechen, zeigen sie Ihnen ein ausgefallenes Diagramm mit einer Latenz von 0 Millisekunden und richten dann einen Hefter auf Sie.

Fragen Sie sie stattdessen nach dem Netzwerkpfad zum SAN. Holen Sie sich Geschwindigkeiten, wenn es mehrwegig ist usw. 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 validieren. Wenn sie sich nicht wieder aneinanderreihen, ist es höchstwahrscheinlich das Netzwerk.

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

Eine Sache, die Sie tun können, um diese Dinge als DBA zu vermeiden, ist sicherzustellen, dass Ihre Wartung und alle anderen datenintensiven Aufgaben (wie ETL) nicht gleichzeitig ausgeführt werden. Das kann definitiv viel Druck auf die Speichernetzwerke ausüben.

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

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

26
Erik Darling

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

Ich verbringe mein Leben damit, auf schlecht gestaltete Hardwareplattformen zu stoßen, auf denen die Leute nur versuchen, einen großen Computer zu entwerfen. Die gesamte CPU-Leistung hier, alle Festplatten dort ... hoffentlich gibt es keinen Remote-RAM. Und das Traurigste ist, dass sie die mangelnde Effizienz dieses Designs durch riesige Server ausgleichen, die zehnmal mehr kosten, als sie sollten. Ich habe gesehen, dass 400.000 US-Dollar langsamer sind als ein 1.000-Dollar-Laptop.

Eine SQL Server-Software ist eine sehr fortschrittliche Software, die alle Hardware-Teile, CPU-Kerne, CPU-Cache, TLB, RAM, Festplattencontroller, Festplatten-Cache ... ausnutzt. Sie enthalten fast die gesamte Dateisystemlogik. Sie werden auf normalen Computern entwickelt und auf High-End-Systemen verglichen. Daher muss ein SQL Server über eigene Festplatten verfügen. Die Installation auf einem SAN ist wie das "Emulieren" eines Computers. Sie verlieren alle Leistungsoptimierungen. SANs dienen zum Speichern von Sicherungen, unveränderlichen Dateien und Dateien, an die Sie nur Daten anhängen (Protokolle).

Rechenzentrumsadministratoren tendieren dazu, alles, was sie können, in SANs zu platzieren, da sie auf diese Weise nur einen Speicherpool verwalten können. Dies ist einfacher als die Pflege des Speichers auf jedem Server. Es ist eine "Ich will meinen Job nicht machen" -Entscheidung und eine sehr schlechte, weil sie sich dann mit Leistungsproblemen auseinandersetzen müssen und das ganze Unternehmen darunter leidet. Installieren Sie einfach die Software auf der Hardware, für die sie entwickelt wurde. Halte es einfach. Achten Sie auf die E/A-Bandbreite, den Cache- und Kontextwechsel-Overhead und den Ressourcen-Jitter (tritt auf, wenn die Ressource gemeinsam genutzt wird). Sie werden am Ende 1/10 der Geräte für die gleiche Ausgangsleistung warten, Ihrem Ops-Team viele Kopfschmerzen ersparen, eine Leistung erzielen, die Ihre Endbenutzer glücklich und produktiver macht, Ihr Unternehmen zu einem besseren Arbeitsplatz machen und Sparen Sie viel Energie (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 im Vergleich zu einem SAN nicht erkennen. Selbst mit Daten und Transaktionsprotokolldateien auf demselben Laufwerk erhalten Sie eine 500-fache Verbesserung. Ein SQL Server auf dem neuesten Stand der Technik verfügt über eine schnelle separate SSD für Daten und Transaktionsprotokoll auf verschiedenen Hardware-Controller-Kanälen (die meisten Server-Motherboards verfügen über mehrere). Aber im Vergleich zu Ihrem aktuellen Setup sprechen wir dort von Sci-Fi. Probieren Sie einfach SSD aus.

8
bokan

Ok, für alle Interessierten,

Wir haben das Problem in Frage vor einigen Monaten gelöst, indem wir einfach 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 dessen, was ich getan habe, um zu diesem Thema zu recherchieren (unter Verwendung von Empfehlungen aus allen Beiträgen zu dieser Frage), bevor wir uns für die Installation von SSD-Laufwerken entschieden haben:

1) hat begonnen, PerfMon-Zähler für folgende Laufwerke auf allen 3 Servern zu sammeln:

Disk F: Ist eine logische Festplatte, die auf SAN basiert und MDF Datendateien) enthält
Disk I: Ist eine logische Festplatte, die auf SAN basiert und LDF-Protokolldateien enthält
Disk T: Ist eine direkt angeschlossene SSD, die ausschließlich tempDB gewidmet ist

Das Bild unten zeigt Durchschnittswerte für einen Zeitraum von 2 Wochen

(Disk Performance Counters

Disk I: (LDF) hat ein so kleines IO und die Latenz ist sehr gering, so dass Disk I: ignoriert werden kann
Sie können sehen, dass Disk T: (TempDB) größer IO im Vergleich zu Disk F: (MDF) ist und gleichzeitig eine viel bessere Latenz hat - 0 Frau

Offensichtlich stimmt etwas mit Datenträger F nicht: Wo sich Datendateien befinden, hat er trotz niedriger E/A-Vorgänge eine hohe Latenz und eine durchschnittliche durchschnittliche Schreibwarteschlange für Datenträger

2) Überprüfte Latenz für einzelne Datenbanken mithilfe der 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
Was interessant ist, Master- und MSDB-Datenbankdateien hatten eine Leselatenz von bis zu 90 ms, was angesichts der geringen Größe ihrer Daten und der geringen IO - ein weiterer Hinweis darauf, dass etwas nicht stimmt) verdächtig ist SAN

3) Es gab keine spezifischen Zeiten

Währenddessen wurden Meldungen "SQL Server ist aufgetreten ..." angezeigt
Als diese Nachrichten protokolliert wurden, wurde keine wartungs- oder festplattenlastige ETL ausgeführt

4) Windows-Ereignisanzeige

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

5) Beginn der Überprüfung der Top-10-Abfragen

Von sp_BlitzCache (CPU, Lesevorgänge usw.) und wenn möglich omptimieren
Keine super IO schwere Abfragen, die Tonnen von Daten abwerfen und den Speicher stark beeinträchtigen würden
Die Indizierung in Datenbanken ist in Ordnung, ich behalte es bei

6) Wir haben kein SAN Team)

Wir haben nur 1 Systemadministrator, der gelegentlich hilft
Netzwerkpfad zu SAN - es ist mehrwegig, jeder der 3 Server verfügt über 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, sodass ich nicht weiß, wie hoch die Geschwindigkeit sein sollte , und es ist nicht möglich, ein Benchmarking durchzuführen an diesem Punkt, um zu sehen, wie hoch die Geschwindigkeiten derzeit sind, da dies die Produktion beeinflusst hätte

8) Richten Sie die Sitzung "Erweiterte Ereignisse" für das Checkpoint-Ereignis für die betreffende Datenbank ein

Mithilfe der XE-Sitzung konnte festgestellt werden, dass der Checkpoint während der Meldung "SQL Server ist aufgetreten ..." sehr langsam war (bis zu 90 Sekunden).

9) SQL Server-Fehlerprotokoll

Enthält "FlushCache" "Saturation" -Einträge
Diese sollen angezeigt werden, wenn die Prüfpunktzeit für eine bestimmte Datenbank die Einstellungen für das Wiederherstellungsintervall überschreitet

Details zeigten, dass die Datenmenge, die der Checkpoint zu leeren versucht, gering ist und lange dauert, bis sie abgeschlossen ist. Die Gesamtgeschwindigkeit beträgt ungefähr 0,25 MB/s ... seltsam

10) Schließlich zeigt dieses Bild eine Tabelle zur Fehlerbehebung beim Speicher:

(Slow Disk IO Troubleshooting Steps

Es scheint, dass wir einfach 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 ..." Slow Checkpoint und 15 Sekunden E/A-Warnungen im Flash-Speicher Sean hatte eine sehr gute Liste, welche Elemente auf Hardware- und Software-Ebene überprüft werden müssen, um Fehler zu beheben

Unser Systemadministrator konnte nicht alle Dinge aus der Liste überprüfen, daher haben wir uns einfach dafür entschieden, Hardware für dieses Problem zu verwenden - es war überhaupt nicht teuer

Auflösung:

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

Da wir über Verfügbarkeitsgruppen verfügen, wurden DB-Datendateien von SAN auf SSD auf sekundären Replikaten migriert, dann 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 vollständige/diff/log-Sicherungen werden im genannten SAN durchgeführt
In den Windows Event Viewer-Protokollen sind keine Meldungen mehr "SQL Server ist aufgetreten ..." aufgetreten, und die Leistung von Sicherungen, Integritätsprüfungen, Indexwiederherstellungen, Abfragen usw. hat erheblich zugenommen

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

Um die Auswirkungen zu bewerten, werden Windows Performance Monitor-Protokolle 2 Wochen vor der Migration und 4 Wochen nach der Migration verwendet:

(Windows Performance Monitor Disk Latency Metrics

Im Folgenden finden Sie auch einen Vergleich der Latenzstatistiken auf DB-Ebene (verwendete die von SQL Server erfassten Statistiken für virtuelle Dateien vor und nach der Migration).

(SQL Server Virtual File Stats

Zusammenfassung

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

Durch die Umstellung auf eine lokale SSD wurden nicht nur Probleme mit der Speicherleistung behoben, sondern auch die Datensicherheit, die mir Sorgen machte (wenn SAN schlägt fehl, verlieren alle 3 Server gleichzeitig ihre Daten).

2
Aleksey Vitsko