Überwachen der Leistung mit dem Abfragespeicher

GILT FÜR: Azure Database for PostgreSQL – Single Server

Wichtig

Azure Database for PostgreSQL – Single Server wird eingestellt. Es wird dringend empfohlen, ein Upgrade auf Azure Database for PostgreSQL – Flexible Server auszuführen. Weitere Informationen zum Migrieren zu Azure Database for PostgreSQL – Flexible Server finden Sie unter Was geschieht mit Azure Database for PostgreSQL – Single Server?

Das Abfragespeicherfeature in Azure Database for PostgreSQL bietet eine Möglichkeit, um die Abfrageleistung im Zeitverlauf nachzuverfolgen. Der Abfragespeicher vereinfacht das Beheben von Leistungsproblemen, da er es Ihnen ermöglicht, die am längsten ausgeführten und ressourcenintensivsten Abfragen schnell zu ermitteln. Der Abfragespeicher erfasst automatisch einen Verlauf der Abfragen und Laufzeitstatistiken und bewahrt diese auf, damit Sie sie überprüfen können. Er unterteilt die Daten nach Zeitfenstern, damit Sie Verwendungsmuster für Datenbanken erkennen können. Die Daten für alle Benutzer, Datenbanken und Abfragen werden in einer Datenbank namens azure_sys in der Azure Database for PostgreSQL-Instanz gespeichert.

Wichtig

Nehmen Sie an der azure_sys-Datenbank oder ihren Schemas keine Änderungen vor. Andernfalls funktionieren der Abfragespeicher und die entsprechenden Leistungsfeatures nicht mehr ordnungsgemäß.

Aktivieren des Abfragespeichers

Der Abfragespeicher ist ein optionales Feature. Daher ist er auf einem Server nicht standardmäßig aktiviert. Der Speicher wird global für alle Datenbanken auf einem bestimmten Server aktiviert oder deaktiviert. Ein Aktivieren oder Deaktivieren für einzelne Datenbanken ist nicht möglich.

Aktivieren des Abfragespeichers über das Azure-Portal

  1. Melden Sie sich beim Azure-Portal an, und wählen Sie Ihren Azure Database for PostgreSQL-Server aus.
  2. Wählen Sie im Bereich Einstellungen im Menü die Option Serverparameter.
  3. Suchen Sie nach dem Parameter pg_qs.query_capture_mode.
  4. Legen Sie für den Wert TOP fest und Speichern.

So aktivieren Sie Wartestatistiken in Ihrem Abfragespeicher:

  1. Suchen Sie nach dem Parameter pgms_wait_sampling.query_capture_mode.
  2. Legen Sie für den Wert ALL fest und Speichern.

Alternativ können Sie diese Parameter über die Azure-Befehlszeilenschnittstelle festlegen.

az postgres server configuration set --name pg_qs.query_capture_mode --resource-group myresourcegroup --server mydemoserver --value TOP
az postgres server configuration set --name pgms_wait_sampling.query_capture_mode --resource-group myresourcegroup --server mydemoserver --value ALL

Es kann bis zu 20 Minuten dauern, bis der erste Datenbatch in der azure_sys-Datenbank gespeichert ist.

Informationen im Abfragespeicher

Der Abfragespeicher verfügt über zwei Speicher:

  • Ein Speicher für Laufzeitstatistiken zum Aufbewahren der Informationen aus den Abfragespeicherstatistiken.
  • Ein Speicher für Wartestatistiken zum Aufbewahren der Informationen aus den Wartestatistiken.

Häufige Szenarien für die Verwendung des Abfragespeichers sind u.a.:

  • Bestimmen der Häufigkeit zum Ausführen einer Abfrage in einem angegebenen Zeitfenster
  • Vergleichen der durchschnittlichen Ausführungsdauer einer Abfrage für bestimmte Zeitfenster zum Anzeigen großer Abweichungen
  • Identifizieren der am längsten ausgeführten Abfragen in der vergangenen X Stunden
  • Identifizieren der wichtigsten N Abfragen, die auf Ressourcen warten
  • Erhalten von Wartedetails einer bestimmten Abfrage

Um die Speicherverwendung zu minimieren, werden die Laufzeit-Ausführungsstatistiken im Speicher für Laufzeitstatistiken für ein festes, konfigurierbares Zeitfenster zusammengefasst. Die Informationen in diesem Speicher können durch Abfragen der Abfragespeicheransichten angezeigt werden.

Zugreifen auf Abfragespeicherinformationen

Abfragespeicherdaten werden in der Datenbank „azure_sys“ auf Ihrem Postgres-Server gespeichert.

Die folgende Abfrage gibt Informationen über Abfragen im Abfragespeicher zurück:

SELECT * FROM query_store.qs_view; 

Diese Abfrage gibt Informationen über Wartestatistiken zurück:

SELECT * FROM query_store.pgms_wait_sampling_view;

Suchen von Warteanfragen

Warteereignistypen kombinieren verschiedene Warteereignisse nach Ähnlichkeit in Buckets. Der Abfragespeicher enthält den Warteereignistyp, den spezifischen Warteereignisnamen und die entsprechende Abfrage. Die Möglichkeit zum Korrelieren dieser Warteinformationen mit den Abfragelaufzeitstatistiken bedeutet, dass Sie einen ausführlicheren Überblick darüber erhalten, welche Faktoren sich auf die Abfrageleistung auswirken.

Im Folgenden finden Sie einige Beispiele dafür, wie Sie mithilfe der Wartestatistiken im Abfragespeicher weitere Erkenntnisse zur Ihrer Workload erhalten:

Beobachtung Aktion
Lange Sperrwartevorgänge Überprüfen Sie die Abfragetexte der betroffenen Abfragen, und identifizieren Sie die Zielentitäten. Suchen Sie im Abfragespeicher nach anderen Abfragen, die die gleiche Entität ändern, welche häufig ausgeführt wird bzw. eine lange Dauer aufweist. Nachdem Sie diese Abfragen ermittelt haben, ändern Sie ggf. die Anwendungslogik, um die Parallelität zu verbessern, oder verwenden Sie eine weniger restriktive Isolationsstufe.
Lange Puffer-E/A-Wartevorgänge Suchen Sie die Abfragen mit einer hohen Anzahl an physischen Lesevorgängen im Abfragespeicher. Wenn diese mit Abfragen mit langen E/A-Wartevorgängen übereinstimmen, führen Sie ggf. einen Index für die zugrunde liegenden Entität ein, um Such- anstelle von Scanvorgängen durchzuführen. Dies verringert den E/A-Aufwand der Abfragen. Überprüfen Sie die Leistungsempfehlungen für Ihren Server im Portal, um festzustellen, ob Indexempfehlungen für diesen Server vorhanden sind, die die Abfragen optimieren.
Lange Arbeitsspeicher-Wartevorgänge Suchen Sie die im Abfragespeicher die speicherintensivsten Abfragen. Diese Abfragen verzögern wahrscheinlich zusätzlich den Fortschritt der betroffen Abfragen. Überprüfen Sie die Leistungsempfehlungen für Ihren Server im Portal, um festzustellen, ob Indexempfehlungen vorhanden sind, die diese Abfragen optimieren.

Konfigurationsoptionen

Wenn der Abfragespeicher aktiviert ist, speichert er Daten in Aggregationsfenstern von 15 Minuten mit bis zu 500 unterschiedlichen Abfragen pro Fenster.

Die folgenden Optionen stehen für die Konfiguration der Abfragespeicherparameter zur Verfügung.

Parameter Beschreibung Standard Bereich
pg_qs.query_capture_mode Legt fest, welche Anweisungen nachverfolgt werden. none none, top, all
pg_qs.max_query_text_length Legt die maximale Abfragelänge fest, die gespeichert werden kann. Längere Abfragen werden abgeschnitten. 6000 100 – 10.000
pg_qs.retention_period_in_days Legt den Aufbewahrungszeitraum fest. 7 1 – 30
pg_qs.track_utility Legt fest, ob Dienstprogrammbefehle nachverfolgt werden. on on, off

Die folgenden Optionen gelten speziell für Wartestatistiken.

Parameter Beschreibung Standard Bereich
pgms_wait_sampling.query_capture_mode Legt fest, welche Anweisungen in Bezug auf Wartestatistiken nachverfolgt werden. none none, all
Pgms_wait_sampling.history_period Legt die Häufigkeit in Millisekunden fest, mit der Stichproben von Wartezeitereignissen erfasst werden. 100 1 – 600000

Hinweis

pg_qs.query_capture_mode ersetzt pgms_wait_sampling.query_capture_mode. Wenn für pg_qs.query_capture_mode NONE festgelegt ist, hat die Einstellung pgms_wait_sampling.query_capture_mode keine Auswirkungen.

Verwenden Sie das Azure-Portal oder die Azure-Befehlszeilenschnittstelle zum Abrufen oder Festlegen eines anderen Werts für einen Parameter.

Ansichten und Funktionen

Mithilfe der folgenden Ansichten und Funktionen können Sie den Abfragespeicher anzeigen und verwalten. In der öffentlichen PostgreSQL-Rolle kann jeder diese Ansichten verwenden, um die Daten im Abfragespeicher anzuzeigen. Diese Ansichten sind nur in der azure_sys-Datenbank verfügbar.

Abfragen werden normalisiert, indem ihre Struktur nach dem Entfernen von Literalen und Konstanten untersucht wird. Wenn zwei Abfragen mit Ausnahme von Literalwerten identisch sind, haben sie denselben Hash.

query_store.qs_view

Diese Ansicht gibt alle Abfragetextdaten im Abfragespeicher zurück. Für jeden einzelnen query_text gibt es eine Zeile. Die Daten sind nicht über den Abschnitt Intelligente Leistung im Portal, über APIs oder über die CLI verfügbar. Sie finden sie jedoch, indem Sie eine Verbindung mit azure_sys herstellen und "query_store.query_texts_view" abfragen.

Name Typ Referenzen Beschreibung
runtime_stats_entry_id BIGINT Die ID aus der Tabelle runtime_stats_entries
user_id oid pg_authid.oid Die OID des Benutzers, der die Anweisung ausgeführt hat
db_id oid pg_database.oid Die OID der Datenbank, in der die Anweisung ausgeführt wurde
query_id BIGINT Interner Hash, der von der Analysestruktur der Anweisung berechnet wurde
query_sql_text Varchar(10000) Der Text einer repräsentativen Anweisung. Unterschiedliche Abfragen mit der gleichen Struktur werden gruppiert; dieser Text ist der Text für die erste Abfrage im Cluster.
plan_id BIGINT ID des Plans, der dieser Abfrage entspricht, noch nicht verfügbar
start_time timestamp Abfragen werden nach Zeitrahmen zusammengefasst. Die Zeitspanne eines Zeitrahmens beträgt standardmäßig 15 Minuten. Dies ist die Startzeit des Zeitrahmens für diesen Eintrag.
end_time timestamp Dies ist die Endzeit des Zeitrahmens für diesen Eintrag.
calls BIGINT Häufigkeit der Abfrageausführung
total_time double precision Gesamte Abfrageausführungsdauer in Millisekunden
min_time double precision Mindestwert der Abfrageausführungsdauer in Millisekunden
max_time double precision Höchstwert der Abfrageausführungsdauer in Millisekunden
mean_time double precision Durchschnittliche Abfrageausführungsdauer in Millisekunden
stddev_time double precision Standardabweichung der Abfrageausführungsdauer in Millisekunden
rows BIGINT Gesamtanzahl der Zeilen, die abgerufen wurden oder von der Anweisung betroffen sind
shared_blks_hit BIGINT Gesamtanzahl der freigegebenen Blockcachetreffer der Anweisung
shared_blks_read BIGINT Gesamtanzahl der freigegebenen Blöcke, die von der Anweisung gelesen wurden
shared_blks_dirtied BIGINT Gesamtanzahl der freigegebenen Blöcke, die von der Anweisung geändert wurden
shared_blks_written BIGINT Gesamtanzahl der freigegebenen Blöcke, die von der Anweisung geschrieben wurden
local_blks_hit BIGINT Gesamtanzahl der lokalen Blockcachetreffer der Anweisung
local_blks_read BIGINT Gesamtanzahl der lokalen Blöcke, die von der Anweisung gelesen wurden
local_blks_dirtied BIGINT Gesamtanzahl der lokalen Blöcke, die von der Anweisung geändert wurden
local_blks_written BIGINT Gesamtanzahl der lokalen Blöcke, die von der Anweisung geschrieben wurden
temp_blks_read BIGINT Gesamtanzahl der temporären Blöcke, die von der Anweisung gelesen wurden
temp_blks_written BIGINT Gesamtanzahl der temporären Blöcke, die von der Anweisung geschrieben wurden
blk_read_time double precision Gesamte Zeit, die die Anweisung zum Lesen von Blöcken benötigt hat, in Millisekunden (wenn track_io_timing aktiviert ist, andernfalls Null)
blk_write_time double precision Gesamte Zeit, die die Anweisung zum Schreiben von Blöcken benötigt hat, in Millisekunden (wenn track_io_timing aktiviert ist, andernfalls Null)

query_store.query_texts_view

Diese Ansicht gibt alle Abfragetextdaten im Abfragespeicher zurück. Für jeden einzelnen query_text gibt es eine Zeile.

Name Typ Beschreibung
query_text_id BIGINT ID der Tabelle query_texts
query_sql_text Varchar(10000) Der Text einer repräsentativen Anweisung. Unterschiedliche Abfragen mit der gleichen Struktur werden gruppiert; dieser Text ist der Text für die erste Abfrage im Cluster.

query_store.pgms_wait_sampling_view

Diese Ansicht gibt alle Abfragetextdaten im Abfragespeicher zurück. Für jeden einzelnen query_text gibt es eine Zeile. Die Daten sind nicht über den Abschnitt Intelligente Leistung im Portal, über APIs oder über die CLI verfügbar. Sie finden sie jedoch, indem Sie eine Verbindung mit azure_sys herstellen und "query_store.query_texts_view" abfragen.

Name Typ Referenzen Beschreibung
user_id oid pg_authid.oid Die OID des Benutzers, der die Anweisung ausgeführt hat
db_id oid pg_database.oid Die OID der Datenbank, in der die Anweisung ausgeführt wurde
query_id BIGINT Interner Hash, der von der Analysestruktur der Anweisung berechnet wurde
event_type text Der Typ des Ereignisses, auf das das Back-End wartet
Ereignis text Der Warteereignisname, wenn das Back-End derzeit wartet
calls Integer Nummer des gleichen erfassten Ereignisses

Functions

Query_store.qs_reset() gibt „void“ zurück

qs_reset verwirft alle Statistiken, die bisher vom Abfragespeicher gesammelt werden. Diese Funktion kann nur von der Serveradministratorrolle ausgeführt werden.

Query_store.staging_data_reset() gibt „void“ zurück

staging_data_reset verwirft alle Statistiken, die vom Abfragespeicher im Arbeitsspeicher erfasst werden (d.h. die Daten im Arbeitsspeicher, für die noch kein Flushvorgang in die Datenbank durchgeführt wurde). Diese Funktion kann nur von der Serveradministratorrolle ausgeführt werden.

Azure Monitor

Azure Database for PostgreSQL ist in die Azure Monitor-Diagnoseeinstellungen integriert. Mit Diagnoseeinstellungen können Sie Ihre Postgres-Protokolle im JSON-Format an Azure Monitor-Protokolle (Analyse und Warnungen), Event Hubs (Streaming) und Azure Storage (Archivierung) senden.

Wichtig

Dieses Diagnosefeature steht nur in den Tarifen „Universell“ und „Arbeitsspeicheroptimiert“ zur Verfügung.

Konfigurieren von Diagnoseeinstellungen

Sie können die Diagnoseeinstellungen für Ihren Postgres-Server über Azure-Portal, die CLI, die REST-API und PowerShell aktivieren. Die zu konfigurierenden Protokollkategorien sind QueryStoreRuntimeStatistics und QueryStoreWaitStatistics.

So aktivieren Sie Ressourcenprotokolle über das Azure-Portal:

  1. Wechseln Sie im Portal im Navigationsmenü Ihres Postgres-Servers zu „Diagnoseeinstellungen“.
  2. Wählen Sie „Diagnoseeinstellung hinzufügen“ aus.
  3. Benennen Sie die Einstellung.
  4. Wählen Sie Ihren bevorzugten Endpunkt aus (Speicherkonto, Event Hub, Log Analytics).
  5. Wählen Sie die Protokolltypen QueryStoreRuntimeStatistics und QueryStoreWaitStatistics aus.
  6. Speichern Sie die Einstellungen.

Informationen zum Aktivieren dieser Einstellung über PowerShell, die CLI oder die REST-API finden Sie im Artikel zu den Diagnoseeinstellungen.

JSON-Protokollformat

In den folgenden Tabellen werden die Felder für die beiden Protokolltypen beschrieben. Je nach dem ausgewählten Ausgabeendpunkt können die enthaltenen Felder und ihre Reihenfolge variieren.

QueryStoreRuntimeStatistics

Feld Beschreibung
TimeGenerated [UTC] Zeitstempel für den Aufzeichnungsbeginn des Protokolls in UTC
resourceId Der Azure-Ressourcen-URI für den Postgres-Server
Category QueryStoreRuntimeStatistics
Vorgangsname QueryStoreRuntimeStatisticsEvent
LogicalServerName_s Der Name des Postgres-Servers
runtime_stats_entry_id_s Die ID aus der Tabelle runtime_stats_entries
user_id_s Die OID des Benutzers, der die Anweisung ausgeführt hat
db_id_s Die OID der Datenbank, in der die Anweisung ausgeführt wurde
query_id_s Interner Hash, der von der Analysestruktur der Anweisung berechnet wurde
end_time_s Die Endzeit des Zeitrahmens für diesen Eintrag
calls_s Häufigkeit der Abfrageausführung
total_time_s Gesamte Abfrageausführungsdauer in Millisekunden
min_time_s Mindestwert der Abfrageausführungsdauer in Millisekunden
max_time_s Höchstwert der Abfrageausführungsdauer in Millisekunden
mean_time_s Durchschnittliche Abfrageausführungsdauer in Millisekunden
ResourceGroup Die Ressourcengruppe
SubscriptionId Ihre Abonnement-ID
ResourceProvider Microsoft.DBForPostgreSQL
Resource Der Name des Postgres-Servers
ResourceType Servers

QueryStoreWaitStatistics

Feld Beschreibung
TimeGenerated [UTC] Zeitstempel für den Aufzeichnungsbeginn des Protokolls in UTC
resourceId Der Azure-Ressourcen-URI für den Postgres-Server
Category QueryStoreWaitStatistics
Vorgangsname QueryStoreWaitEvent
user_id_s Die OID des Benutzers, der die Anweisung ausgeführt hat
db_id_s Die OID der Datenbank, in der die Anweisung ausgeführt wurde
query_id_s Der interne Hash der Abfrage
calls_s Nummer des gleichen erfassten Ereignisses
event_type_s Der Typ des Ereignisses, auf das das Back-End wartet
event_s Der Warteereignisname, wenn das Back-End derzeit wartet
start_time_t Die Startzeit des Ereignisses
end_time_s Die Endzeit des Ereignisses
LogicalServerName_s Der Name des Postgres-Servers
ResourceGroup Die Ressourcengruppe
SubscriptionId Ihre Abonnement-ID
ResourceProvider Microsoft.DBForPostgreSQL
Resource Der Name des Postgres-Servers
ResourceType Servers

Einschränkungen und bekannte Probleme

  • Wenn ein PostgreSQL-Server über den Parameter „default_transaction_read_only“ verfügt, kann der Abfragespeicher keine Daten erfassen.
  • Die Funktion des Abfragespeichers kann durch lange Unicodeabfragen (>= 6.000 Bytes) unterbrochen werden.
  • Lesereplikate replizieren Abfragespeicherdaten des primären Servers. Das bedeutet, dass der Abfragespeicher eines Lesereplikats keine Statistikdaten zu Abfragen bereitstellt, die für das Lesereplikat ausgeführt werden.

Nächste Schritte