Abfrageleistung mit erweiterten Query Insights-Funktionen überwachen

Wählen Sie eine Dokumentationsversion aus:

Mit erweiterten Abfragestatistiken können Sie Probleme mit der Abfrageleistung in Ihrer AlloyDB Omni-Datenbank erkennen, diagnostizieren und verhindern. Dabei werden Telemetriedaten der Datenbank erfasst, einschließlich normalisierter Abfragestatistiken, Warteereignisse, Client-IP-Adressen, Tags und Instanzlast. Verlaufsdaten werden 30 Tage lang aufbewahrt.

Mit erweiterten Query Insights können Sie folgende Aufgaben ausführen:

  • Abfragen mit hoher Latenz und ressourcenintensive Abfragen identifizieren, indem Sie Ausführungszeit, E/A-Zeit, Wartezeit, Aktivität des gemeinsamen Zwischenspeichers und Zeilenanzahl analysieren.
  • Engpässe beheben, indem Sie langsame Abfragen mit Warteereignissen und Warteereignisklassen korrelieren.
  • Die Abfrageleistung bestimmten Anwendungskomponenten zuordnen, indem Sie Abfragen mit SQLCommenter Metadaten taggen.
  • Aktive Abfragen und offene Transaktionen in Echtzeit überwachen und problematische Sitzungen beenden.

Hinweis

Prüfen Sie vor dem Aktivieren der erweiterten Query Insights, ob die folgenden Anforderungen erfüllt sind:

  • Sie verwenden eine eigenständige AlloyDB Omni-Instanz, die mit Linux-RPM-Paketen installiert wurde.

  • Sie haben postgres-Superuserzugriff auf die Datenbankinstanz und Administratorzugriff, um den Datenbankdienst neu zu starten.

  • Die Datenbank alloydbadmin ist auf Ihrer Instanz vorhanden. AlloyDB Omni erstellt diese Datenbank standardmäßig bei der Initialisierung.

Erweiterte Abfragestatistiken aktivieren

So aktivieren Sie Query Insights:

  1. Stellen Sie als postgres-Superuser eine Verbindung zur Datenbank postgres her:

    sudo -u postgres /usr/lib/postgresql/18/bin/psql -U postgres -d postgres

  2. Prüfen Sie die geladenen Bibliotheken in shared_preload_libraries, fügen Sie erweiterte Query Insights zur Vorabladeliste hinzu, aktivieren Sie die Erweiterung und beenden Sie psql:

    SHOW shared_preload_libraries;
ALTER SYSTEM SET shared_preload_libraries = 'LIBRARY_1','LIBRARY_2','google_insights_v2';
ALTER SYSTEM SET google_insights_v2.enabled = on;
\q

    Ersetzen Sie LIBRARY_1, LIBRARY_2 und alle zusätzlichen vorhandenen Bibliotheken durch die Bibliotheksnamen, die von SHOW shared_preload_libraries zurückgegeben werden. Setzen Sie jeden einzelnen Bibliothekseintrag in einfache Anführungszeichen, z. B. 'g_stats','google_columnar_engine','google_insights_v2', und fügen Sie alle vorhandenen Bibliotheken ein, die von AlloyDB Omni benötigt werden, damit Sie sie nicht überschreiben.

  3. Starten Sie den AlloyDB Omni-Server neu, um die Vorabladeeinstellungen anzuwenden:

    sudo systemctl restart alloydbomni18

  4. Stellen Sie als postgres-Superuser eine Verbindung zur Datenbank alloydbadmin her:

    sudo -u postgres /usr/lib/postgresql/18/bin/psql -U postgres -d alloydbadmin

  5. Erstellen Sie die Erweiterung für erweiterte Query Insights in der Datenbank alloydbadmin:

    CREATE EXTENSION IF NOT EXISTS google_insights_v2;

  6. Prüfen Sie, ob die Bibliothek geladen, die Erweiterung aktiviert und die Erweiterung google_insights_v2 in alloydbadmin installiert ist:

    SHOW shared_preload_libraries;
SHOW google_insights_v2.enabled;
SELECT extname, extversion FROM pg_extension WHERE extname = 'google_insights_v2';

    Bestätigen Sie, dass shared_preload_libraries die Erweiterung google_insights_v2 enthält, google_insights_v2.enabled den Wert on zurückgibt und dass pg_extension eine Zeile für google_insights_v2 zurückgibt.

Dimensionen und Parameter für Funktionen

In AlloyDB Omni zeichnet Query Insights Datenbanktelemetriedaten in SQL-Tabellen, Ansichten und Funktionen in der Datenbank alloydbadmin für die folgenden Dimensionen und Funktionen auf:

  • Abfragen: Verwenden Sie diese Dimension, um langsame oder ressourcenintensive SQL-Anweisungen zu identifizieren, wenn die Abfragelatenz zunimmt.
  • Warteereignistypen: Verwenden Sie diese Dimension, um zu ermitteln, ob CPU, Festplatten-E/A oder Sperrkonflikte Engpässe bei der Arbeitslast verursachen.
  • Warteereignisse: Verwenden Sie diese Dimension, um das spezifische PostgreSQL-Warteereignis zu identifizieren, z. B. DataFileRead oder WALWrite, das die Abfrageausführung verzögert.
  • Datenbanken: Verwenden Sie diese Dimension, um den Ressourcenverbrauch zwischen logischen Datenbanken zu vergleichen und Datenbanken mit hoher Last auf freigegebenen Instanzen zu isolieren.
  • Nutzer und Client-IP-Adressen: Verwenden Sie diese Dimension, um die Abfragelast bestimmten Datenbankrollen oder Client-IP-Adressen zuzuordnen und problematische Anwendungsclients zu identifizieren.
  • Tags: Verwenden Sie diese Dimension, um die Datenbanklast mit bestimmten Anwendungsdiensten, Routen oder ORM-Aktionen zu korrelieren, die mit SQLCommenter getaggt sind.
  • Aktive Abfragen: Verwenden Sie diese Dimension, um Leistungsspitzen, blockierte Transaktionen und lang andauernde Sitzungen in Echtzeit zu diagnostizieren.

Wenn Sie google_insights_v2.enabled auf on setzen, erfasst AlloyDB Omni automatisch Messwerte für Abfragen, Warteereignistypen, Warteereignisse, Datenbanken und Nutzer.

Wenn Sie einen google_insights_v2.*-Parameter zur Laufzeit aktualisieren möchten, ohne den Datenbankserver neu zu starten, führen Sie ALTER SYSTEM SET aus und laden Sie die Konfiguration neu:

ALTER SYSTEM SET PARAMETER_NAME = VALUE;
SELECT pg_reload_conf();

Ersetzen Sie Folgendes:

  • PARAMETER_NAME: Der Name des zu konfigurierenden Parameters für erweiterte Query Insights, z. B. google_insights_v2.qi_track_active_queries, google_insights_v2.qi_track_tag oder google_insights_v2.qi_track_client_address.
  • VALUE: Der neue Wert für den Parameter, z. B. on.

Beschreibungen der einzelnen Parameter, der entsprechenden Ansichten für die Beobachtbarkeit sowie der Messwerte und Spalten, die von jeder Ansicht zurückgegeben werden, finden Sie unter Referenz zu erweiterten Abfragestatistiken.

Zeitliche Detaillierungsgrade

Jede observability_service_*-Ansicht mit Verlaufsdaten ist mit drei zeitlichen Detaillierungsgraden verfügbar:

  • Basisansichten (*_view): 15-Sekunden-Intervalle. Verwenden Sie diese Ansichten, um aktuelle Spitzen oder Vorfälle in den letzten 1 bis 6 Stunden zu untersuchen.
  • Ansichten der groben Ebene 1 (*_coarse_1_view): Aggregierte 5-Minuten-Intervalle für die 2.000 wichtigsten Abfragen. Verwenden Sie diese Ansichten, um Leistungstrends über 6 bis 24 Stunden zu analysieren.
  • Ansichten der groben Ebene 2 (*_coarse_2_view): Aggregierte 30-Minuten-Intervalle für die 2.000 wichtigsten Abfragen. Verwenden Sie diese Ansichten, um Trends über mehrere Tage bis zum Aufbewahrungslimit von 30 Tagen zu analysieren.

In den Ansichten für die Beobachtbarkeit mit Verlaufsdaten werden alle Spalten für Ausführungs-, Warte- und E/A-Zeit in Mikrosekunden gespeichert, einschließlich total_execution_time, total_wait_time, total_read_time, total_write_time und time_spent.

Verlaufsdaten der Abfrageleistung abfragen

Stellen Sie eine Verbindung zur Datenbank alloydbadmin her, um Diagnoseabfragen für die Ansichten für die Beobachtbarkeit mit Verlaufsdaten auszuführen. Weitere Informationen finden Sie unter AlloyDB Omni ausführen und eine Verbindung herstellen.

Die SQL-Anweisungen in diesem Abschnitt sind Beispielabfragen für häufige Szenarien zur Fehlerbehebung in den verschiedenen Dimensionen. Sie können diese Beispiele an Ihre Arbeitslast anpassen, z. B. den Zeitraum recorded_on ändern, nach bestimmten Datenbanken oder Rollen filtern oder *_coarse_1_view und *_coarse_2_view für Analysen über mehrere Tage abfragen.

Abfragen mit hoher Latenz identifizieren

Führen Sie die folgende Beispielabfrage für google_insights_v2.observability_service_query_view aus, um die 10 wichtigsten normalisierten Abfragen mit der höchsten Gesamtausführungszeit in der letzten Stunde zu finden:

SELECT
  query_id,
  database,
  username,
  left(query, 100) AS normalized_query,
  sum(count) AS total_executions,
  sum(total_execution_time) AS total_execution_time_us,
  round((sum(total_execution_time)::numeric / NULLIF(sum(count), 0)), 2) AS avg_execution_time_us,
  sum(total_rows) AS total_rows,
  sum(total_shared_blocks_hit) AS shared_blocks_hit,
  sum(total_shared_blocks_read) AS shared_blocks_read
FROM google_insights_v2.observability_service_query_view
WHERE recorded_on >= now() - INTERVAL '1 hour'
GROUP BY query_id, database, username, left(query, 100)
ORDER BY total_execution_time_us DESC
LIMIT 10;

Warteereignisse nach Abfrage analysieren

Führen Sie die folgende Beispielabfrage für google_insights_v2.observability_service_wait_event_stats_by_query_view aus, um zu ermitteln, welche Warteereigniskategorien (wait_class) und detaillierten Warteereignisse (wait_event) die meiste Wartezeit für eine bestimmte query_id verursachen:

SELECT
  query_id,
  database,
  username,
  wait_class,
  wait_event,
  sum(count) AS wait_occurrences,
  sum(time_spent) AS total_wait_time_us
FROM google_insights_v2.observability_service_wait_event_stats_by_query_view
WHERE recorded_on >= now() - INTERVAL '1 hour'
  AND query_id = QUERY_ID
GROUP BY query_id, database, username, wait_class, wait_event
ORDER BY total_wait_time_us DESC;

Ersetzen Sie QUERY_ID durch den Wert query_id, der von observability_service_query_view zurückgegeben wird.

Datenbank-, Nutzer- und Client-IP-Last analysieren

Führen Sie die folgende Beispielabfrage für google_insights_v2.observability_service_db_load_conn_view aus, um die Gesamtausführungszeit, die Wartezeit und das Abfragevolumen für logische Datenbanken und Datenbankrollen in der letzten Stunde zu vergleichen:

SELECT
  database,
  username,
  sum(count) AS total_executions,
  sum(total_execution_time) AS total_execution_time_us,
  sum(total_wait_time) AS total_wait_time_us
FROM google_insights_v2.observability_service_db_load_conn_view
WHERE recorded_on >= now() - INTERVAL '1 hour'
GROUP BY database, username
ORDER BY total_execution_time_us DESC;

Wenn Sie google_insights_v2.qi_track_client_address aktivieren, können Sie mit der folgenden Beispielabfrage für google_insights_v2.observability_service_client_address_stats_by_query_view auch ermitteln, welche Client-IP-Adressen die meiste Abfragezeit verursachen:

SELECT
  client_address,
  username,
  database,
  query_id,
  sum(count) AS total_executions,
  sum(time_spent) AS total_time_spent_us
FROM google_insights_v2.observability_service_client_address_stats_by_query_view
WHERE recorded_on >= now() - INTERVAL '1 hour'
GROUP BY client_address, username, database, query_id
ORDER BY total_time_spent_us DESC
LIMIT 10;

Abfrageleistung nach Tags verfolgen

Wenn google_insights_v2.qi_track_tag auf on gesetzt ist und Ihre Abfragen SQLCommenter Kommentare enthalten, führen Sie die folgende Beispielabfrage aus, um die Ausführungszeit nach Metadaten für Anwendungstags zu aggregieren. Verwenden Sie dazu google_insights_v2.observability_service_tag_view:

SELECT
  application,
  framework_name,
  framework_controller,
  framework_action,
  framework_route,
  database,
  username,
  sum(count) AS total_executions,
  sum(total_execution_time) AS total_execution_time_us,
  round((sum(total_execution_time)::numeric / NULLIF(sum(count), 0)), 2) AS avg_execution_time_us
FROM google_insights_v2.observability_service_tag_view
WHERE recorded_on >= now() - INTERVAL '1 hour'
GROUP BY
  application,
  framework_name,
  framework_controller,
  framework_action,
  framework_route,
  database,
  username
ORDER BY total_execution_time_us DESC
LIMIT 10;

Aktive Abfragen überwachen

Wenn Sie google_insights_v2.qi_track_active_queries auf on setzen, können Sie laufende Abfragen und offene Transaktionen in Echtzeit überwachen, indem Sie google_insights_v2.stat_activity und google_insights_v2.stat_activity_v3 in der Datenbank alloydbadmin abfragen.

In diesen Ansichten werden aktive Clientverbindungen, Sitzungs- und Transaktionsdauern sowie aktuelle Warteereignisse angezeigt. Hintergrundprozesse und alloydbadmin-Verbindungen werden dabei ausgeschlossen.

Aktive Sitzungen und Transaktionsdauern abfragen

Führen Sie die folgende Beispielabfrage in alloydbadmin aus, um zu ermitteln, welche Abfragen derzeit auf der Instanz ausgeführt werden und welche Transaktionen am längsten laufen:

SELECT
  pid AS "Process ID",
  left(normalized_query, 40) AS "Query",
  state AS "Status",
  round(EXTRACT(EPOCH FROM (clock_timestamp() - backend_start))::numeric, 2) AS "Session duration (secs)",
  CASE
    WHEN xact_start IS NOT NULL
    THEN round(EXTRACT(EPOCH FROM (clock_timestamp() - xact_start))::numeric, 2)
    ELSE NULL
  END AS "Transaction duration (secs)",
  CASE
    WHEN query_start IS NOT NULL
    THEN round(EXTRACT(EPOCH FROM (clock_timestamp() - query_start))::numeric, 2)
    ELSE NULL
  END AS "Query duration (secs)",
  COALESCE(wait_event_type, '') AS "Wait event type",
  COALESCE(wait_event, '') AS "Wait event",
  database AS "Database",
  COALESCE(application_name, '') AS "Application name",
  username AS "Username",
  COALESCE(client_addr::text, '') AS "Client address"
FROM google_insights_v2.stat_activity_v3
WHERE state = 'active'
ORDER BY query_start ASC;

Lang andauernde Abfrage oder Transaktion beenden

Wenn Sie eine lang andauernde Abfrage oder blockierte Transaktion beenden möchten, die in google_insights_v2.stat_activity_v3 identifiziert wurde, übergeben Sie die Prozess-ID an pg_terminate_backend:

SELECT pg_terminate_backend(PROCESS_ID);

Ersetzen Sie PROCESS_ID durch den Wert Process ID (pid), der von google_insights_v2.stat_activity_v3 zurückgegeben wird.

Erweiterte Query Insights deaktivieren

Wenn Sie die Erfassung von Telemetriedaten beenden möchten, ohne Ihre AlloyDB Omni-Instanz neu zu starten, setzen Sie google_insights_v2.enabled auf off und laden Sie die Konfiguration neu:

ALTER SYSTEM SET google_insights_v2.enabled = off;
SELECT pg_reload_conf();

Wenn Sie die Erweiterungsobjekte und gespeicherten Verlaufsdaten aus der Datenbank alloydbadmin entfernen möchten, stellen Sie eine Verbindung zu alloydbadmin her und löschen Sie die Erweiterung:

DROP EXTENSION IF EXISTS google_insights_v2 CASCADE;

Nächste Schritte