Erkunden von Leistungsszenarien

  • 5 Minuten

Um zu entscheiden, wie Leistungstools und -funktionen verwendet werden, ist es wichtig, die Leistung für Azure SQL in Szenarien zu betrachten.

Grundlegendes zu allgemeinen Leistungsszenarien

Eine gängige Methode zur Behandlung von Leistungsproblemen bei SQL Server besteht darin, zu untersuchen, ob ein Leistungsproblem bei der Ausführung (hohe CPU) oder beim Warten (Warten auf eine Ressource) auftritt. Das folgende Diagramm zeigt eine Entscheidungsstruktur, anhand derer festgestellt werden kann, ob ein SQL Server-Leistungsproblem bei der Ausführung oder beim Warten auftritt und wie Leistungstools zur Ursachenermittlung und Lösung eingesetzt werden können.

Diagramm von „Wird ausgeführt“ im Vergleich zu „Wartend“

Sehen Sie sich zunächst die allgemeine Ressourcennutzung an. Für eine SQL Server-Standardbereitstellung können Sie Tools wie den Leistungsmonitor unter Windows oder Top unter Linux verwenden. Für Azure SQL können Sie die folgenden Methoden verwenden:

  • Azure-Portal/PowerShell/Warnungen

    Azure Monitor verfügt über integrierte Metriken, um die Ressourcennutzung für Azure SQL anzuzeigen. Zudem können Sie Warnungen einrichten, um nach Bedingungen für die Ressourcennutzung zu suchen.

  • sys.dm_db_resource_stats

    Für Azure SQL-Datenbank können Sie sich diese DMV ansehen, um die CPU-, Arbeitsspeicher- und E/A-Ressourcennutzung für die Datenbankbereitstellung zu sehen. Diese DMV nimmt alle 15 Sekunden eine Momentaufnahme dieser Daten auf.

  • sys.server_resource_stats

    Diese DMV verhält sich zwar genau wie sys.dm_db_resource_stats, dient jedoch dazu, die Ressourcennutzung der verwalteten Instanz für die CPU, den Arbeitsspeicher und die E/A anzuzeigen. Diese DMV erstellt ebenfalls alle 15 Sekunden eine Momentaufnahme.

  • sys.dm_user_db_resource_governance

    Für Azure SQL-Datenbank gibt diese DMV die tatsächlichen Konfigurations- und Kapazitätseinstellungen zurück, die von Ressourcengovernancemechanismen in der aktuellen Datenbank oder dem Pool für elastische Datenbanken verwendet werden.

  • sys.dm_instance_resource_governance

    Für Azure SQL Managed Instance gibt diese DMV ähnliche Informationen wie sys.dm_user_db_resource_governance zurück, aber für die aktuelle SQL Managed Instance.

Laufen

Wenn Sie festgestellt haben, dass das Problem eine hohe CPU-Auslastung ist, wird dies als „Wird ausgeführt“-Szenario bezeichnet. Dies kann Abfragen beinhalten, die durch Kompilierung oder Ausführung Ressourcen verbrauchen. Führen Sie mithilfe der folgenden Tools eine genauere Analyse durch:

  • Abfragespeicher

    Verwenden Sie die Berichte über die Ressourcen mit dem höchsten Verbrauch in SSMS, Katalogsichten im Abfragespeicher oder Query Performance Insight im Azure-Portal (nur Azure SQL-Datenbank), um herauszufinden, welche Abfragen die meisten CPU-Ressourcen verbrauchen.

  • sys.dm_exec_requests

    Verwenden Sie diese DMV in Azure SQL, um eine Momentaufnahme des Zustands der aktiven Abfragen zu erhalten. Suchen Sie nach Abfragen mit dem Status RUNNABLE und dem Wartetyp SOS_SCHEDULER_YIELD, um herauszufinden, ob genügend CPU-Kapazität vorhanden ist.

  • sys.dm_exec_query_stats

    Mit dieser DMV können Sie, ähnlich wie mit dem Abfragespeicher, die Abfragen finden, die den höchsten Ressourcenverbrauch aufweisen. Sie ist nur für zwischengespeicherte Abfragepläne verfügbar, während der Abfragespeicher einen dauerhaften Leistungsverlauf bereitstellt. Mit dieser DMV können Sie auch nach dem Abfrageplan für eine zwischengespeicherte Abfrage suchen.

  • sys.dm_exec_procedure_stats

    Diese DMV stellt Informationen auf ähnliche Weise wie sys.dm_exec_query_stats zur Verfügung. Der Unterschied besteht darin, dass die Leistungsdaten auf der Ebene der gespeicherten Prozedur angezeigt werden können.

    Nachdem Sie ermittelt haben, welche Abfragen die meisten Ressourcen beanspruchen, müssen Sie möglicherweise überprüfen, ob genügend CPU-Ressourcen für Ihre Arbeitsauslastung vorhanden sind. Abfragepläne können mit Tools wie der einfachen Abfrageprofilerstellung, SET-Anweisungen, dem Abfragespeicher oder der Ablaufverfolgung für erweiterte Ereignisse gedebuggt werden.

Warten

Wenn das Problem offenbar nicht in einer zu hohen CPU-Auslastung besteht, könnte es mit dem Warten auf eine Ressource zusammenhängen. Zu den Szenarios, die das Warten auf Ressourcen beinhalten, gehören:

  • E/A-Wartevorgänge
  • Sperrwartevorgänge
  • Latchwartevorgänge
  • Pufferpoollimits
  • Speicherzuweisungen
  • Plancacheentfernung

Um Analysen zu Warteszenarien durchzuführen, werden in der Regel die folgenden Tools verwendet:

  • sys.dm_os_wait_stats

    Verwenden Sie diese DMV, um zu ermitteln, welche die häufigsten Wartetypen für die Datenbank bzw. Instanz sind. Anhand der am häufigsten auftretenden Wartetypen können Sie ermitteln, welche Maßnahmen als Nächstes zu ergreifen sind.

  • sys.dm_exec_requests

    Mit dieser DMV können Sie bestimmte Wartetypen für aktive Abfragen finden, um festzustellen, auf welche Ressource sie warten. Hierbei kann es sich um ein Standardsperrszenario handeln, in dem auf Sperrungen von anderen Benutzern gewartet wird.

  • sys.dm_os_waiting_tasks

    Sie können diesen DMV verwenden, um Wartetypen für eine bestimmte Aufgabe für eine bestimmte Abfrage zu finden, die derzeit ausgeführt wird, vielleicht um zu sehen, warum es länger dauert als normal. sys.dm_os_waiting_tasks enthält die Live-Wartezeitstatistiken, die sys.dm_os_wait_stats im Laufe der Zeit aggregiert.

  • Abfragespeicher

    Abfragespeicher bietet Berichte und Katalogsichten, die eine Aggregation der häufigsten Wartevorgänge für die Ausführung von Abfrageplänen zeigen. Beachten Sie, dass das Warten der CPU einem Problem bei der Ausführung gleichkommt.

Spezifische Szenarios für Azure SQL

Es gibt einige Leistungsszenarios, sowohl für die Ausführung als auch das Warten, die nur in Azure SQL auftreten. Hierzu gehören die Protokollgovernance, Workerlimits, Wartevorgänge für Dienstebenen des Typs „Unternehmenskritisch“ und Wartevorgänge, die für Hyperscale-Bereitstellungen spezifisch sind.

Protokollgovernance

In Azure SQL können mithilfe der Protokollratengovernance Ressourcenlimits für die Verwendung von Transaktionsprotokollen durchgesetzt werden. Diese Maßnahme ist häufig erforderlich, um Ressourcenlimits und die zugesagte SLA einzuhalten. Die Protokollgovernance kann unter folgenden Gesichtspunkten betrachtet werden:

  • LOG_RATE_GOVERNOR: wartet auf Azure SQL-Datenbank
  • POOL_LOG_RATE_GOVERNOR: wartet auf Pools für elastische Datenbanken
  • INSTANCE_LOG_GOVERNOR: wartet auf Azure SQL Managed Instance
  • HADR_THROTTLE_LOG_RATE*: wartet auf Vorgänge des Typs „Unternehmenskritisch“ und Georeplikationslatenz

Workerlimits

SQL Server verwendet einen Workerpool von Threads, verfügt jedoch über Grenzwerte für die maximale Anzahl von Workern. Anwendungen mit einer großen Anzahl gleichzeitiger Benutzer*innen können sich den Workerlimits nähern, die für Azure SQL-Datenbank und SQL Managed Instance durchgesetzt werden:

  • Azure SQL-Datenbank ist in Bezug auf die Dienstebene und den Umfang begrenzt. Wenn Sie diese Grenzwerte überschreiten, tritt bei einer neuen Abfrage ein Fehler auf.
  • Derzeit verwendet SQL Managed Instance max worker threads, sodass für Worker, die dieses Limit überschreiten, THREADPOOL-Wartevorgänge auftreten.

Unternehmenskritische HADR-Wartevorgänge

Wenn Sie eine Dienstebene des Typs „Unternehmenskritisch“ nutzen, können unerwartet die folgenden Wartetypen auftreten:

  • HADR_SYNC_COMMIT
  • HADR_DATABASE_FLOW_CONTROL
  • HADR_THROTTLE_LOG_RATE_SEND_RECV

Obwohl diese Wartevorgänge Ihre Anwendung unter Umständen nicht verlangsamen, können sie dennoch unerwartet auftreten. Normalerweise treten sie jedoch nur bei Verwendung einer Always On-Verfügbarkeitsgruppe auf. In Dienstebenen des Typs „Unternehmenskritisch“ wird die Technologie der Verfügbarkeitsgruppen eingesetzt, um SLA-Features und Verfügbarkeitsfeatures zu implementieren. Mit diesen Wartetypen ist also zu rechnen. Lange Wartezeiten können auf einen Engpass hinweisen, z. B. auf E/A-Latenz oder ein verzögertes Replikat.

Hyperskalierung

Die Hyperscale-Architektur kann zu einigen einzigartigen Wartetypen führen, die mit RBIO vorangestellt sind (ein möglicher Hinweis auf die Protokollgovernance). Darüber hinaus wurden dynamische Verwaltungssichten (DMVs), Katalogsichten und erweiterte Ereignisse verbessert und zeigen nun Metriken für Seitenlesevorgänge des Servers an.

In der folgenden Übung erfahren Sie, wie Sie mit den Tools und dem Wissen, das Sie in dieser Lerneinheit erworben haben, ein Leistungsproblem für Azure SQL überwachen und lösen.