Älteste aktive Abfragen, auch als Abfragen mit längster Ausführungszeit bezeichnet, sind eine Liste von Abfragen, die in Ihrer Datenbank aktiv sind, sortiert nach der ausgeführt wird. Einblicke in diese Abfragen können helfen, die Ursachen von Systemlatenzen und hoher CPU-Auslastung während deren Auftreten zu erkennen.
Spanner bietet eine integrierte Tabelle,SPANNER_SYS.OLDEST_ACTIVE_QUERIES
die ausgeführte Abfragen, einschließlich Abfragen mit DML-Anweisungen,
nach Startzeit in aufsteigender Reihenfolge. Änderungsstreamabfragen sind darin nicht enthalten.
Wenn eine große Anzahl von Abfragen ausgeführt wird, sind die Ergebnisse möglicherweise
aufgrund von Speicherbeschränkungen, die das System
die Erhebung dieser Daten erzwingt. Daher wird Spanner
die zusätzliche Tabelle SPANNER_SYS.ACTIVE_QUERIES_SUMMARY
, in der
zusammenfassende Statistiken für alle aktiven Abfragen (außer Änderungsstreamabfragen)
Mit SQL können Sie Informationen aus diesen beiden integrierten Tabellen abrufen.
Aussagen.
In diesem Dokument werden beide Tabellen beschrieben und es werden einige Beispielabfragen gezeigt, bei denen und schließlich zeigen, wie Sie mit ihnen Probleme mindern können, die durch aktive Abfragen verursacht werden.
Verfügbarkeit
SPANNER_SYS
-Daten sind nur über SQL-Schnittstellen verfügbar. Beispiel:
Die Seite Spanner Studio einer Datenbank in der Google Cloud Console
Mit der
executeQuery
API
Andere von Spanner bereitgestellte Methoden für einzelne Leseaufrufe werden nicht unterstützt
SPANNER_SYS
OLDEST_ACTIVE_QUERIES
SPANNER_SYS.OLDEST_ACTIVE_QUERIES
gibt eine Liste aktiver Abfragen zurück, nach Startzeit sortiert. Wird eine große Anzahl von Abfragen ausgeführt,
Ergebnisse können aufgrund des Arbeitsspeichers auf eine Teilmenge der gesamten Abfragen beschränkt sein
Einschränkungen, die Spanner für die Erfassung dieser Daten erzwingt. Bis
zusammenfassende Statistiken für alle aktiven Abfragen anzeigen, siehe
ACTIVE_QUERIES_SUMMARY
Tabellenschema
Spaltenname | Typ | Beschreibung |
---|---|---|
START_TIME |
TIMESTAMP |
Startzeit der Abfrage. |
TEXT_FINGERPRINT |
INT64 |
Der Fingerabdruck ist ein Hash der an der Transaktion beteiligten Vorgänge. |
TEXT |
STRING |
Der Text der Abfrageanweisung. |
TEXT_TRUNCATED |
BOOL |
"True", wenn der Abfragetext im Feld TEXT beschnitten ist. Andernfalls "false". |
SESSION_ID |
STRING |
Die ID der Sitzung, in der die Abfrage ausgeführt wird. Dies wird zur Beobachtbarkeit verwendet. |
QUERY_ID . |
STRING |
Die ID für die Abfrage. Sie verwenden diese ID mit CALL cancel_query("query_id") , um die Abfrage abzubrechen. |
Beispielabfragen
Sie können die folgenden Beispiel-SQL-Anweisungen mit dem Client Bibliotheken, die Google Cloud CLI oder die Google Cloud Console:
Älteste laufende 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
FROM spanner_sys.oldest_active_queries
ORDER BY start_time ASC;
start_time | text_fingerprint | text | text_truncated | session_id |
---|---|---|---|---|
2020-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; | False | ACjbPvYsucrtcffHrRK6aObeIjZf12tSUwOsim-g1WC3IhqF4epzICCQR3GCHw |
2020-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; | False | ACjbPvaF3yKiNfxXFod2LPoFaXjKR759Bw1o34206vv0t7eOrD3wxZhu8U6ohQ |
2020-07-18T07:54:08.631744Z | -105437553161169030 | 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 > 7 LIMIT 1000000; | False | ACjbPvanq3MesDNT98t64KdKAz3TlDZoCC-zgW-FJn91cJHuczQ_cOFN_Hdflw |
2020-07-18T07:54:08.720011Z | -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; | False | ACjbPvYIE2QHkhnmMXuAGpB4inK7yMnQjmYgQ9FoygKNaB5KCXu7Sf7f9aghYw |
2020-07-18T07:54:08.731006Z | 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 | ACjbPvYNZ06N2YyvwV0YMlSRBNDtXBqZEK-iAAyPFnFcTmshPvzWkhr034ud7w |
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;
Ausgabe der Abfrage
start_time | text_fingerprint | text | text_truncated | session_id |
---|---|---|---|---|
2020-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; | False | ACjbPvYsucrtcffHrRK6aObeIjZf12tSUwOsim-g1WC3IhqF4epzICCQR3GCHw |
2020-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; | False | ACjbPvaF3yKiNfxXFod2LPoFaXjKR759Bw1o34206vv0t7eOrD3wxZhu8U6ohQ |
ACTIVE_QUERIES_SUMMARY
Wie der Name verrät, zeigt die integrierte Tabelle SPANNER_SYS.ACTIVE_QUERIES_SUMMARY
eine Zusammenfassungsstatistik für alle aktiven Abfragen an. Wie im folgenden Schema gezeigt, werden Abfragen nach Alter in drei Buckets oder Zähler gruppiert, die älter als eine Sekunde, älter als 10 Sekunden und älter als 100 Sekunden sind.
Tabellenschema
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 dem Client Bibliotheken, die gcloud spanner oder der Google Cloud Console:
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 | 2020-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.
OLDEST_ACTIVE_QUERIES
kann in Lese-Schreib-Transaktionen nicht verwendet werden. 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 FehlerABORTED
mit Teilergebnissen zurückgegeben werden. Verwerfen Sie in diesem Fall die Teilergebnisse und versuchen Sie anschließend, die Abfrage noch einmal auszuführen.
Daten zu aktiven Abfragen verwenden, um Fehler bei hoher CPU-Auslastung zu beheben
Abfragestatistiken und Transaktionsstatistiken liefern nützliche Informationen für die Fehlerbehebung bei der Latenz in einer Spanner-Datenbank. Diese Tools liefern Informationen über die bereits abgeschlossen sind. Manchmal müssen Sie jedoch wissen, was im System läuft. Stellen Sie sich zum Beispiel das Szenario vor, Die CPU-Auslastung ist relativ hoch und Sie möchten die folgenden Fragen beantworten.
- Wie viele Abfragen werden aktuell ausgeführt?
- Was sind diese Abfragen?
- Wie viele Abfragen über einen langen Zeitraum ausgeführt werden, d. h. mehr als 100 Sekunden?
- 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.
- Reduzieren Sie die Häufigkeit der Abfrage, wenn sie mit einer Periode verknüpft ist Hintergrundaufgabe.
- Identifizieren des Nutzers oder der Komponente, von der die Suchanfrage stammt, die möglicherweise nicht berechtigt ist, führen Sie die Abfrage aus.
In dieser Schritt-für-Schritt-Anleitung untersuchen wir unsere aktiven Abfragen gegebenenfalls Maßnahmen ergreifen.
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 |
2020-07-18T07:52:28.225877Z |
21 |
21 |
1 |
Wir haben eine Abfrage, die für mehr als 100 Sekunden. 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 etwa 16:44:09 Uhr ausgeführt EDT zurückgegeben und die folgenden Ergebnisse zurückgegeben. (Möglicherweise müssen Sie horizontal, um die gesamte Ausgabe zu sehen.)
start_time | text_fingerprint | text | text_truncated | session_id | query_id |
---|---|---|---|---|---|
28.03.2024 16:44:09.356939+00:00 | -2833175298673875968 | Auswählen * aus spanner_sys.oldest_active_queries | false | ACjbPvYsucrtcffHrRK6aObeIjZf12tSUwOsim-g1WC3IhqF4epzICCQR3GCHw | 37190103859320827 |
2020-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; | false | ACjbPvaF3yKiNfxXFod2LPoFaXjKR759Bw1o34206vv0t7eOrD3wxZhu8U6ohQ | 48946620525959556 |
Die älteste Suchanfrage (fingerprint = -2833175298673875968
) wird hervorgehoben in der
. Es ist ein teurer CROSS JOIN
. Wir entscheiden uns, einzugreifen.
Teure Abfrage abbrechen
In diesem Beispiel haben wir eine Abfrage gefunden,
die ein teures CROSS JOIN
ausführt,
brechen wir die Abfrage ab. Die Abfrageergebnisse in den vorherigen
Schritt enthielt ein query_id
. Wir können Folgendes ausführen:
Befehl CALL cancel_query(query_id)
für GoogleSQL und den
spanner.cancel_query(query_id)
-Befehl für PostgreSQL, um
brechen Sie die Abfrage ab.
GoogleSQL
CALL cancel_query(query_id)
PostgreSQL
CALL spanner.cancel_query(query_id)
Im folgenden Beispiel bricht die CALL
-Anweisung eine Abfrage mit dem Parameter
ID 37190103859320827
:
CALL cancel_query(37190103859320827)
Sie müssen die Tabelle spanner_sys.oldest_active_queries
abfragen, um zu prüfen, ob der
Abfrage abgebrochen.
In dieser Schritt-für-Schritt-Anleitung wird gezeigt, wie Sie SPANNER_SYS.OLDEST_ACTIVE_QUERIES
und
SPANNER_SYS.ACTIVE_QUERIES_SUMMARY
, um unsere laufenden Abfragen zu analysieren
falls notwendig bei Abfragen, die zur hohen CPU-Auslastung beitragen. 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
- Weitere Informationen zu Tools zur Selbstbeobachtung
- Weitere Informationen zu weiteren Informationen, die Spanner für jede Datenbank speichert in den Informationsschematabellen der Datenbank.
- Best Practices für SQL für Spanner.