Leidet Ihr Server unter einer übermäßigen Anzahl von E/A-Warnungen? Wenn ja, sollten Sie sich über eine Verschlechterung der Serverleistung Sorgen machen? Wie kann man das zugrunde liegende Problem am besten diagnostizieren und E/A-Engpässe beseitigen?
Der E/A-Stallzeitalarm von Spotlight Cloud ist ein guter Indikator für E/A-Engpässe. Er wird ausgelöst, wenn die durchschnittliche Wartezeit pro Vorgang einer Datenbankdatei den Alarmschwellenwert überschreitet. Der Alarm verwendet Daten aus sys.dm_io_virtual_file_stats DMVs für seine Berechnungen. Es verwendet einen Durchschnittswert, der nach fünf Sammlungen in den letzten 15 Minuten abgeleitet wurde, sodass Sie nicht bei gelegentlichen Spitzen gewarnt werden. Die Alarmbeschreibung umfasst den Namen der virtuellen Datenbankdatei, den Datenbanknamen und die durchschnittliche Wartezeit pro E/A-Vorgang.
Vier einfache Vorschläge zur Diagnose von E/A-bezogenen Problemen in Spotlight Cloud:
1. Überprüfen Sie, was zum E/A-Verbrauch beiträgt.
Der E/A-Verbrauch ist ein Zeichen für die Latenz von Festplattensubsystemen, die durch Arbeitsspeicher- oder CPU-Auslastung, schlecht geschriebene Abfragen oder keine gute Mischung von Indizes verursacht werden kann. Zum Zeitpunkt des Alarms:
Nutzen Sie zunächst den Bereich „Eigenschaften“ auf der rechten Seite der Seite „Alarme“, um Smart Alarms-bezogene Daten anzuzeigen:
1. Details des Alarms, einschließlich Dateiname, durchschnittliche E/A-Wartezeit für die Datei und Dauer des Alarms
2. Analysieren Sie die gesammelten Daten, die im Trenddiagramm der letzten Stunden
Diagnostizieren Sie als Nächstes das Problem, indem Sie auf die Schaltfläche Diagnose klicken. Das führt Sie zum Dashboard E/A nach Datei, das sich auf die gestresste Datei konzentriert. Sie können dieses und andere Dashboards zur weiteren Diagnose verwenden:
1. E/A nach Datei – Identifizieren Sie die Dateien, die direkt von E/A betroffen sind
2. Workload Analyzer – Die wichtigsten SQL-Anweisungen und der TSQL-Batch, die die meisten E/A-Vorgänge verbrauchen
3. Sitzungen – Sitzungen zum Zeitpunkt mit Festplattenaktivität
4. Zustandsprüfung – Überprüfen Sie, ob Indizes fehlen
2. Überprüfen Sie Dateien, die auf E/A-Operationen warten.
Das Dashboard „E/A nach Datei“ identifiziert die Dateien, die auf E/A-Vorgänge warten. Untersuchen Sie die folgenden E/A-Statistiken:
1. Notieren Sie sich die E/A-bezogenen Spalten:E/A-Raten, Lese-/Schreibraten und Warteraten
2. Sortieren Sie die Dateien nach ihrer durchschnittlichen Wartezeit pro /IO, indem Sie auf die blaue Dropdown-Liste direkt über der Spalte Logische Datei drücken.
3. Sehen Sie sich die Lese- und Schreibaktivität in der letzten Stunde an, die für die Datei generiert wurde, die in den Feldern auf der rechten Seite angezeigt wird.
4. Erweitern Sie optional den Zeitrahmen, um zu prüfen, ob dies ein normales Verhalten der Datei ist.
5. Sollten Sie im Laufe der Zeit eine Reihe von Dateien sehen, die unter demselben Problem leiden und den Speicherort oder die Festplatte gemeinsam nutzen, sollten Sie deren Speicherort anpassen und die E/A-Konflikte zwischen Festplatten oder Speicherorten vergleichen, um die Probleme mit der Festplattenlatenz zu verringern.
6. Falls Tempdb-Datenbankdateien ein wichtiger Faktor sind, verwenden Sie das TempDB-Nutzungs-Dashboard, um die Aktivität für die Datenbank anzuzeigen:
a. Tempdb-Datenbankdateien und ihre Statistiken
b. Sitzungen, die tempdb verwenden
c. Top-Tabellen und -Indizes, die in tempdb erstellt wurden
3. Finden Sie SQL-Anweisungen, die möglicherweise große Mengen logischer E/A ausführen.
Das Workload Analyzer-Dashboard zeigt die wichtigsten E/A, die SQL verbrauchen:
1. Klicken Sie im oberen Banner auf die E/A-Ressource und erweitern Sie den Knoten „SQL-Anweisung“ in der Dimensionsstruktur, um die 25 SQL-verbrauchenden E/A während des Zeitraums anzuzeigen.
2. Konzentrieren Sie sich auf eine Anweisung und erweitern Sie den Bereich SQL-Anweisungseigenschaften auf der rechten Seite, um die Details des SQL- und Abfrageplans anzuzeigen.
3. Laden Sie die SQL-Anweisung in SSMS, indem Sie die Option „In SSMS öffnen“ verwenden, und verwenden Sie das Plug-in-Tool Tuning Pack, um den Plan zu analysieren oder eine optimalere Anweisung neu schreiben zu lassen.
4. Konzentrieren Sie sich auf den Knoten „SQL-Anweisung“ der Dimensionsstruktur, um die SQL-Anweisungen aufzulisten. Sortieren Sie die Sitzungen nach IO Wait oder Logical Reads. Verwenden Sie den Bereich Mit übergeordnetem Element vergleichen auf der rechten Seite, um die IO-Wartezeit einer einzelnen SQL mit dem Rest von SQL in der Instanz zu vergleichen, die IO verwendet. Die logische E/A kann zu unnötiger physischer E/A führen.
4. Überprüfen Sie, welche SQL Server-Sitzungen eine hohe Festplattenaktivität erzeugen.
Das Sitzungs-Dashboard zeigt die Sitzungen an, die in der Instanz geöffnet sind. Um die Sitzungen anzuzeigen, die eine hohe Festplattenaktivität erzeugen, überprüfen Sie die E/A-bezogenen Statistiken und sortieren Sie danach.
1. E/A-bezogene Statistiken weisen Sie in die richtige Richtung:Gesamt-E/A, logische Lesevorgänge, physische Lesevorgänge und Anforderungs-E/A
2. Der rechte Bereich der Registerkarte Sitzung zeigt zusätzliche Statistiken zusammen mit dem zugrunde liegenden SQL
Verwenden Sie das Tempdb-Bedienfeld, um Sitzungen anzuzeigen, die die Tempdb-Datenbank verwenden:
1. Verwenden Sie das Tempdb-Dashboard, um die Sitzungen und Objekte zu identifizieren, die die Datenbank verwenden
2. Verwenden Sie das Tempdb-Nutzungs-Dashboard, um alle Sitzungen über einen bestimmten Zeitraum anzuzeigen
Übernehmen Sie die Kontrolle über die E/A-Latenz, indem Sie die Diagnosefunktionen von Spotlight Cloud nutzen!
