Statistiken zu ältesten aktiven Abfragen

Die ältesten aktiven Abfragen, auch längste laufende Abfragen genannt, sind eine Liste der in der Datenbank aktiven Abfragen, sortiert nach ihrer Laufzeit. Einblicke in diese Abfragen können helfen, die Ursachen von Systemlatenzen und hoher CPU-Auslastung während deren Auftreten zu erkennen.

Spanner bietet die integrierte Tabelle SPANNER_SYS.OLDEST_ACTIVE_QUERIES. Die Liste enthält laufende Abfragen, einschließlich solcher, die DML-Anweisungen enthalten, in aufsteigender Reihenfolge nach Startzeit sortiert. Change Stream-Abfragen sind nicht enthalten.

Wenn viele Abfragen ausgeführt werden, sind die Ergebnisse aufgrund der Speichereinschränkungen, die das System bei der Erfassung dieser Daten erzwingt, möglicherweise auf eine Teilmenge der Gesamtabfragen beschränkt. Daher bietet Spanner die zusätzliche Tabelle SPANNER_SYS.ACTIVE_QUERIES_SUMMARY, in der Sammelstatistiken für alle aktiven Abfragen (außer Änderungsstream-Abfragen) angezeigt werden. Sie können Informationen aus beiden integrierten Tabellen mit SQL-Anweisungen abrufen.

In diesem Dokument beschreiben wir beide Tabellen, zeigen einige Beispielabfragen, die diese Tabellen verwenden, und demonstrieren schließlich, wie Sie sie verwenden können, um Probleme durch aktive Abfragen abzuweisen.

Statistiken zu den ältesten aktiven Abfragen aufrufen

SPANNER_SYS-Daten sind nur über SQL-Schnittstellen verfügbar. Beispiel:

Spanner unterstützt SPANNER_SYS nicht mit den folgenden Einzellesemethoden:

  • Starken Lesevorgang aus einer einzelnen Zeile oder mehreren Zeilen in einer Tabelle durchführen
  • Veralteten Lesevorgang aus einer einzelnen Zeile oder mehreren Zeilen in einer Tabelle durchführen
  • Aus einer einzelnen Zeile oder mehreren Zeilen in einem sekundären Index lesen

Statistik für OLDEST_ACTIVE_QUERIES

SPANNER_SYS.OLDEST_ACTIVE_QUERIES gibt eine Liste aktiver Abfragen zurück, nach Startzeit sortiert. Wenn viele Abfragen ausgeführt werden, sind die Ergebnisse möglicherweise auf eine Teilmenge der Gesamtabfragen beschränkt, da Spanner aufgrund der Speichereinschränkungen die Erfassung dieser Daten erzwingt. Eine Zusammenfassung aller aktiven Abfragen finden Sie unter ACTIVE_QUERIES_SUMMARY.

Schema für die Statistiktabellen für alle ältesten aktiven Abfragen

Spaltenname Typ Beschreibung
START_TIME TIMESTAMP Startzeit der Abfrage.
TEXT_FINGERPRINT INT64 Der Fingerprint ist ein Hash des Anfrage-Tags oder, falls kein Tag vorhanden ist, ein Hash des Abfragetextes.
TEXT STRING Der Text der Abfrageanweisung.
TEXT_TRUNCATED BOOL Wenn der Abfragetext im Feld TEXT beschnitten ist, lautet dieser Wert TRUE. Wenn der Abfragetext nicht gekürzt wurde, ist dieser Wert FALSE.
SESSION_ID STRING Die ID der Sitzung, in der die Abfrage ausgeführt wird.
QUERY_ID STRING Die ID der Abfrage. Sie können diese ID mit CALL cancel_query(query_id) verwenden, um die Abfrage abzubrechen.
CLIENT_IP_ADDRESS STRING Die IP-Adresse des Clients, der die Abfrage angefordert hat. Manchmal wird die Client-IP-Adresse entfernt. Die hier angezeigte IP-Adresse stimmt mit den Audit-Logs überein und unterliegt denselben Richtlinien für die Schwärzung. Weitere Informationen finden Sie unter IP-Adresse des Anrufers in Audit-Logs. Wir empfehlen, die Client-IP-Adresse nur anzufordern, wenn sie benötigt wird, da Anfragen nach Client-IP-Adressen zu zusätzlicher Latenz führen können.
API_CLIENT_HEADER STRING Der api_client-Header vom Client.
USER_AGENT_HEADER STRING Der user_agent-Header, den Spanner vom Client erhalten hat.
SERVER_REGION STRING Die Region, in der der Spanner-Root-Server die Abfrage verarbeitet. Weitere Informationen finden Sie unter Lebenszyklus einer Anfrage.
PRIORITY STRING Die Priorität der Abfrage. Informationen zu den verfügbaren Prioritäten finden Sie unter RequestOptions.
TRANSACTION_TYPE STRING Der Transaktionstyp der Anfrage. Mögliche Werte sind READ_ONLY, READ_WRITE und NONE.

Beispielabfragen

Sie können die folgenden Beispiel-SQL-Anweisungen mit den Clientbibliotheken, der Google Cloud CLI oder der Google Cloud -Konsole ausführen.

Am längsten laufende aktive Abfragen auflisten

Die folgende Abfrage gibt eine Liste der ältesten laufenden Abfragen zurück, nach Startzeit der Abfrage sortiert.

SELECT start_time,
       text_fingerprint,
       text,
       text_truncated,
       session_id,
       query_id,
       api_client_header,
       server_region,
       priority,
       transaction_type
FROM spanner_sys.oldest_active_queries
ORDER BY start_time ASC;
Screenshot: Ausgabe der Abfrage

In der folgenden Tabelle sehen Sie die Ausgabe, die beim Ausführen der oben genannten Abfrage generiert wird:

start_time text_fingerprint text text_truncated session_id query_id api_client_header server_region Priorität transaction_type
2025-05-20T03:29:54.287255Z -3426560921851907385 SELECT a.SingerId, a.AlbumId, a.TrackId, b.SingerId as b_id, b.AlbumId as b_albumid, b.TrackId as b_trackId FROM Songs as a CROSS JOIN Songs as b; FALSE AG46FS6K3adF 9023439241169932454 gl-go/1.25.0-20250216-RC00 gccl/1.73.0 gapic/1.73.0 gax/2.14.1 grpc/1.69.2 us-central1 PRIORITY_HIGH READ_ONLY
2025-05-20T03:31:52.40808Z 1688332608621812214 SELECT a.SingerId, a.AlbumId, a.TrackId, a.SongName, s.FirstName, s.LastName FROM Songs as a JOIN Singers as s ON s.SingerId = a.SingerId WHERE STARTS_WITH(s.FirstName, 'FirstName') LIMIT 1000000; FALSE AG46FS6paJPKDOb 2729381896189388167 gl-go/1.25.0-20250216-RC00 gccl/1.73.0 gapic/1.73.0 gax/2.14.1 grpc/1.69.2 us-central1 PRIORITY_HIGH READ_WRITE
2025-05-20T03:31:52.591212Z 6561582859583559006 SELECT a.SingerId, a.AlbumId, a.TrackId, a.SongName, s.FirstName, s.LastName FROM Songs as a JOIN Singers as s ON s.SingerId = a.SingerId WHERE a.SingerId > 10 LIMIT 1000000; FALSE AG46FS7Pb_9H6J6p 9125776389780080794 gl-go/1.25.0-20250216-RC00 gccl/1.73.0 gapic/1.73.0 gax/2.14.1 grpc/1.69.2 us-central1 PRIORITY_LOW READ_ONLY

Die beiden am längsten laufenden Abfragen auflisten

Als geringfügige Variation der vorhergehenden Abfrage gibt dieses Beispiel die zwei am längsten laufenden Abfragen zurück, nach Startzeit der Abfrage sortiert.

SELECT start_time,
       text_fingerprint,
       text,
       text_truncated,
       session_id
FROM spanner_sys.oldest_active_queries
ORDER BY start_time ASC LIMIT 2;
Screenshot: Ausgabe der Abfrage

In der folgenden Tabelle sehen Sie die Ausgabe, die beim Ausführen der oben genannten Abfrage generiert wird:

start_time text_fingerprint text text_truncated session_id
2039-07-18T07:52:28.225877Z -3426560921851907385 SELECT a.SingerId, a.AlbumId, a.TrackId, b.SingerId as b_id, b.AlbumId as b_albumid, b.TrackId as b_trackId FROM Songs as a CROSS JOIN Songs as b; Falsch ACjbPvYsuRt
2039-07-18T07:54:08.622081Z -9206690983832919848 SELECT a.SingerId, a.AlbumId, a.TrackId, a.SongName, s.FirstName, s.LastName FROM Songs as a JOIN Singers as s ON s.SingerId = a.SingerId WHERE STARTS_WITH(s.FirstName, 'FirstName') LIMIT 1000000; Falsch ACjbPvaF3yK

ACTIVE_QUERIES_SUMMARY

Die Statistiktabellen SPANNER_SYS.ACTIVE_QUERIES_SUMMARY enthalten eine Zusammenfassungsstatistik für alle aktiven Abfragen. Abfragen werden in die folgenden Gruppen eingeteilt:

  • älter als 1 Sekunde
  • älter als 10 Sekunden
  • älter als 100 Sekunden

Tabellenschema für ACTIVE_QUERIES_SUMMARY

Spaltenname Typ Beschreibung
ACTIVE_COUNT INT64 Die Gesamtzahl der ausgeführten Abfragen.
OLDEST_START_TIME TIMESTAMP Obergrenze für die Startzeit der am längsten laufenden Abfrage.
COUNT_OLDER_THAN_1S INT64 Die Anzahl der Abfragen, die älter als 1 Sekunde sind.
COUNT_OLDER_THAN_10S INT64 Die Anzahl der Abfragen, die älter als 10 Sekunden sind.
COUNT_OLDER_THAN_100S INT64 Die Anzahl der Abfragen, die älter als 100 Sekunden sind.

Abfragen können in mehr als einem dieser Buckets gezählt werden. Beispiel: Wurde eine Abfrage 12 Sekunden lang ausgeführt, so wird sie in COUNT_OLDER_THAN_1S und COUNT_OLDER_THAN_10S gezählt, da sie beide Kriterien erfüllt.

Beispielabfragen

Sie können die folgenden Beispiel-SQL-Anweisungen mit den Clientbibliotheken, gcloud spanner oder der Google Cloud -Konsole ausführen.

Zusammenfassung aktiver Abfragen abrufen

Folgende Abfrage gibt eine Zusammenfassung der Statistiken zur Abfragenausführung zurück.

SELECT active_count,
       oldest_start_time,
       count_older_than_1s,
       count_older_than_10s,
       count_older_than_100s
FROM spanner_sys.active_queries_summary;
Ausgabe der Abfrage
active_count oldest_start_time count_older_than_1s count_older_than_10s count_older_than_100s
22 2039-07-18T07:52:28.225877Z 21 21 1

Beschränkungen

Das Ziel ist es, Ihnen möglichst umfassende Einblicke zu liefern. Es gibt jedoch einige Umstände, unter denen Abfragen nicht in den Daten dieser Tabellen enthalten sind.

  • DML-Abfragen (UPDATE, INSERT, DELETE) werden nicht berücksichtigt, wenn sie sich in der Phase Mutationen anwenden befinden.

  • Eine Abfrage ist nicht enthalten, wenn sie aufgrund eines vorübergehenden Fehlers gerade neu startet.

  • Abfragen von überlasteten oder nicht reagierenden Servern sind nicht enthalten.

  • Das Lesen oder Abfragen der Tabelle OLDEST_ACTIVE_QUERIES kann nicht in einer Lese-Schreib-Transaktion erfolgen. Selbst in schreibgeschützten Transaktionen wird der Transaktionszeitstempel ignoriert und es werden immer aktuelle Daten bei der Ausführung zurückgegeben. In seltenen Fällen kann der Fehler ABORTED mit Teilergebnissen zurückgegeben werden. Verwerfen Sie in diesem Fall die Teilergebnisse und versuchen Sie anschließend, die Abfrage noch einmal auszuführen.

  • Wenn in der Spalte CLIENT_IP_ADDRESS der String <error> zurückgegeben wird, deutet dies auf ein vorübergehendes Problem hin, das sich nicht auf den Rest der Abfrage auswirken sollte. Wiederholen Sie die Abfrage, um die Client-IP-Adresse abzurufen.

Aktive Abfragedaten zur Fehlerbehebung bei hoher CPU-Auslastung verwenden

Abfragestatistiken und Transaktionsstatistiken bieten hilfreiche Informationen zur Fehlerbehebung bei Latenzen in einer Spanner-Datenbank. Diese Tools bieten Informationen zu bereits abgeschlossenen Abfragen. Manchmal müssen Sie jedoch wissen, was im System ausgeführt wird. Stellen Sie sich beispielsweise ein Szenario vor, in dem die CPU-Auslastung relativ hoch ist und Sie folgende Fragen beantworten möchten.

  • Wie viele Abfragen werden aktuell ausgeführt?
  • Was sind diese Abfragen?
  • Wie viele Abfragen werden länger als 100 Sekunden ausgeführt?
  • In welcher Sitzung wird die Abfrage ausgeführt?

Aufgrund der Antworten auf vorhergehende Fragen können Sie folgende Maßnahme ergreifen.

  • Löschen Sie die Sitzung, in der die Abfrage ausgeführt wird, um eine sofortige Lösung zu erhalten.
  • Um die Abfrageleistung zu steigern können Sie einen Index hinzufügen.
  • Verringern Sie die Häufigkeit der Abfrage, falls sie mit einer periodischen Hintergrundaufgabe verknüpft ist.
  • Identifizieren Sie den Nutzer oder die Komponente, die die Abfrage ausführt und möglicherweise nicht zur Ausführung der Abfrage autorisiert ist.

In dieser Schritt-für-Schritt-Anleitung untersuchen wir unsere aktiven Abfragen und ermitteln gegebenenfalls, welche Maßnahmen zu ergreifen sind, falls überhaupt.

Zusammenfassung aktiver Abfragen abrufen

In unserem Beispielszenario bemerken wir eine überdurchschnittliche CPU-Auslastung. Daher führen wir die folgende Abfrage aus, um eine Zusammenfassung der aktiven Abfragen zu erhalten.

SELECT active_count,
       oldest_start_time,
       count_older_than_1s,
       count_older_than_10s,
       count_older_than_100s
FROM spanner_sys.active_queries_summary;

Die Abfrage liefert folgende Ergebnisse.

active_count oldest_start_time count_older_than_1s count_older_than_10s count_older_than_100s
22 2039-07-18T07:52:28.225877Z 21 21 1

Wie sich herausstellt, wird aktuell eine Abfrage ausgeführt, die bereits mehr als 100 Sekunden läuft. Dies ist ungewöhnlich für unsere Datenbank, weshalb wir es genauer untersuchen wollen.

Liste der aktiven Abfragen abrufen

Im vorherigen Schritt haben wir eine Abfrage ausgeführt, die länger als 100 Sekunden lief. Zur weiteren Untersuchung führen wir folgende Abfrage aus, um mehr Informationen zu den fünf am längsten ausgeführten Abfragen zu erhalten.

SELECT start_time,
       text_fingerprint,
       text,
       text_truncated,
       session_id,
       query_id
FROM spanner_sys.oldest_active_queries
ORDER BY start_time ASC LIMIT 5;

In diesem Beispiel haben wir die Abfrage am 28. März 2024 um 16:44:09 Uhr EDT ausgeführt und die folgenden Ergebnisse erhalten. (Möglicherweise müssen Sie horizontal scrollen, um die gesamte Ausgabe zu sehen.)

start_time text_fingerprint text text_truncated session_id query_id
2024-03-28 16:44:09.356939+00:00 -2833175298673875968 select * from spanner_sys.oldest_active_queries falsch ACjbPvYsucrtcffHrRK6aObeIjZf12tSUwOsim-g1WC3IhqF4epzICCQR3GCHw 37190103859320827
2039-07-18T07:52:28.225877Z -3426560921851907385 SELECT a.SingerId, a.AlbumId, a.TrackId, b.SingerId as b_id, b.AlbumId as b_albumid, b.TrackId as b_trackId FROM Songs as a CROSS JOIN Songs as b; falsch ACjbPvaF3yKiNfxXFod2LPoFaXjKR759Bw1o34206vv0t7eOrD3wxZhu8U6ohQ 48946620525959556

In der Tabelle ist die älteste Abfrage (Fingerabdruck = -2833175298673875968) hervorgehoben. Es ist ein teurer CROSS JOIN. Wir entscheiden uns, einzugreifen.

Teure Abfragen abbrechen

In diesem Beispiel haben wir eine Abfrage gefunden, die eine teure CROSS JOIN ausgeführt hat, daher brechen wir die Abfrage ab. Die Abfrageergebnisse, die wir im vorherigen Schritt erhalten haben, enthielten einen query_id. Wir können den folgenden CALL cancel_query(query_id)-Befehl für GoogleSQL und den spanner.cancel_query(query_id)-Befehl für PostgreSQL ausführen, um die Abfrage abzubrechen.

GoogleSQL 

CALL cancel_query(query_id)

PostgreSQL 

CALL spanner.cancel_query(query_id)

Im Folgenden wird beispielsweise mit der Anweisung CALL eine Abfrage mit der ID 37190103859320827 abgebrochen:

CALL cancel_query('37190103859320827')

Sie müssen die Tabelle spanner_sys.oldest_active_queries abfragen, um zu prüfen, ob die Abfrage abgebrochen wurde.

In dieser Schritt-für-Schritt-Anleitung wird gezeigt, wie Sie mit SPANNER_SYS.OLDEST_ACTIVE_QUERIES und SPANNER_SYS.ACTIVE_QUERIES_SUMMARY laufende Abfragen analysieren und bei Bedarf bei Abfragen, die eine hohe CPU-Auslastung bedingen, Schritte ergreifen. Natürlich ist es immer günstiger, teure Vorgänge zu vermeiden und das richtige Schema für den jeweiligen Anwendungsfall zu entwerfen. Weitere Informationen zum Erstellen effizienter SQL-Anweisungen finden sich unter Best Practices für SQL.

Nächste Schritte