Spanner bietet integrierte Tabellen, in denen Statistiken zu Transaktionen gespeichert werden. Mit SQL-Anweisungen können Sie Statistiken aus diesen SPANNER_SYS.TXN_STATS*
-Tabellen abrufen.
Wann werden Transaktionsstatistiken verwendet?
Transaktionsstatistiken sind nützlich, um Leistungsprobleme zu untersuchen. Sie können zum Beispiel prüfen, ob es langsam laufende Transaktionen gibt, die die Leistung oder Abfragen pro Sekunde in Ihrer Datenbank beeinträchtigen könnten. Ein weiteres Szenario ist, wenn Ihre Clientanwendungen eine hohe Latenz bei der Transaktionsausführung aufweisen. Durch die Analyse von Transaktionsstatistiken können Sie potenzielle Engpässe erkennen, z. B. große Mengen an Aktualisierungen einer bestimmten Spalte, die sich auf die Latenz auswirken können.
Verfügbarkeit
SPANNER_SYS
-Daten sind nur über SQL-Schnittstellen verfügbar. Beispiel:
Spanner Studio-Seite einer Datenbank in der Google Cloud Console
Befehl
gcloud spanner databases execute-sql
Dashboard Transaktionsinformationen
Mit der
executeQuery
API
Andere von Spanner bereitgestellte Methoden für einzelne Leseaufrufe unterstützen SPANNER_SYS
nicht.
Nach Transaktion gruppierte Latenzstatistiken
Die folgenden Tabellen verfolgen die Statistiken für die TOP
-ressourcenverbrauchenden Transaktionen während eines bestimmten Zeitraums.
SPANNER_SYS.TXN_STATS_TOP_MINUTE
: Transaktionsstatistiken, zusammengefasst in Intervallen von einer Minute.SPANNER_SYS.TXN_STATS_TOP_10MINUTE
: Transaktionsstatistiken, zusammengefasst in Intervallen von 10 Minuten.SPANNER_SYS.TXN_STATS_TOP_HOUR
: Transaktionsstatistiken, zusammengefasst in Intervallen von einer Stunde.
Diese Tabellen haben folgende Attribute:
Jede Tabelle enthält Daten für nicht überlappende Zeitintervalle in der Länge, die der Tabellenname festlegt.
Intervalle basieren auf Uhrzeiten. 1-Minuten-Intervalle enden zur vollen Minute, 10-Minuten-Intervalle enden alle 10 Minuten ab einer vollen Stunde und 1-Stunden-Intervalle enden zur vollen Stunde.
Beispielsweise sind die neuesten, für SQL-Abfragen verfügbaren Intervalle um 11:59:30 Uhr:
- 1 Minute: 11:58:00–11:58:59 Uhr
- 10 Minuten: 11:40:00–11:49:59 Uhr
- 1 Stunde: 10:00:00–10:59:59 Uhr
Spanner gruppiert die Statistiken nach dem Fprint-Fingerabdruck der Transaktionen. Wenn ein Transaktions-Tag vorhanden ist, ist F der Hash des Tags. Andernfalls ist es der Hash, der anhand der an der Transaktion beteiligten Vorgänge berechnet wird.
Da Statistiken basierend auf FPRINT gruppiert werden, wird dieselbe Transaktion immer noch nur einmal in diesen Tabellen angezeigt, wenn dieselbe Transaktion mehrmals innerhalb eines Zeitintervalls ausgeführt wird.
Jede Zeile enthält Statistiken für alle Ausführungen einer bestimmten Transaktion, für die Spanner während des angegebenen Intervalls Statistiken erfasst.
Wenn Spanner keine Statistiken für alle Transaktionen speichern kann, die während des Intervalls in diesen Tabellen ausgeführt werden, priorisiert das System Transaktionen mit der höchsten Latenz, Commit-Versuche und Byte, die während des angegebenen Intervalls geschrieben wurden.
Tabellenschema
Spaltenname | Typ | Beschreibung |
---|---|---|
INTERVAL_END |
TIMESTAMP |
Ende des Zeitintervalls, in dem die einbezogenen Transaktionen ausgeführt wurden. |
TRANSACTION_TAG |
STRING |
Das optionale Transaktions-Tag für diesen Transaktionsvorgang. Weitere Informationen zur Verwendung von Tags finden Sie unter Fehlerbehebung mit Transaktions-Tags. Statistiken für mehrere Transaktionen mit demselben Tag-String werden in einer einzelnen Zeile gruppiert, wobei die TRANSACTION_TAG diesem Tag-String entspricht. |
FPRINT |
INT64 |
Der Hash von TRANSACTION_TAG , falls vorhanden; andernfalls wird der Hash anhand der Vorgänge berechnet, die an der Transaktion beteiligt sind.
INTERVAL_END und FPRINT bilden zusammen einen eindeutigen Schlüssel für diese Tabellen. |
READ_COLUMNS |
ARRAY<STRING> |
Der Satz von Spalten, die von der Transaktion gelesen wurden. |
WRITE_CONSTRUCTIVE_COLUMNS |
ARRAY<STRING> |
Der Satz von Spalten, die von der Transaktion konstruktiv geschrieben (also neuen Werten zugewiesen) wurden.
Wenn die Transaktion bei Änderungsstreams Schreibvorgänge in Spalten und Tabellen beinhaltet, die von einem Änderungsstream beobachtet werden, enthält WRITE_CONSTRUCTIVE_COLUMNS zwei Spalten: .data und ._exists
1, denen ein Name des Änderungsstreams vorangestellt ist.
|
WRITE_DELETE_TABLES |
ARRAY<STRING> |
Der Satz von Tabellen, in denen Zeilen gelöscht oder durch die Transaktion ersetzt wurden. |
ATTEMPT_COUNT |
INT64 |
Gesamtzahl der Transaktionsversuche, einschließlich der Versuche, die vor dem Aufruf von „commit“ abgebrochen werden. |
COMMIT_ATTEMPT_COUNT |
INT64 |
Gesamtzahl der Commit-Transaktionsversuche. Sie muss mit der Anzahl der Aufrufe der commit -Methode der Transaktion übereinstimmen.
|
COMMIT_ABORT_COUNT |
INT64 |
Die Gesamtzahl der abgebrochenen Transaktionsversuche, einschließlich der abgebrochenen Transaktionsversuche vor dem Aufruf der Methode commit der Transaktion.
|
COMMIT_RETRY_COUNT |
INT64 |
Gesamtzahl der Wiederholungsversuche aus zuvor abgebrochenen Versuchen. Eine Spanner-Transaktion kann aufgrund von Sperrkonflikten oder vorübergehenden Ereignissen mehrmals ausprobiert werden, bevor ein Commit durchgeführt wird. Eine hohe Anzahl von Wiederholungsversuchen im Verhältnis zu Commit-Versuchen deutet auf Probleme hin, die untersucht werden sollten. Weitere Informationen finden Sie unter Transaktionen und Commit-Zählungen auf dieser Seite. |
COMMIT_FAILED_PRECONDITION_COUNT |
INT64 |
Gesamtzahl der Commit-Transaktionsversuche, bei denen fehlgeschlagene Vorbedingungsfehler zurückgegeben wurden, z. B. UNIQUE -Indexverstöße, Zeile ist bereits vorhanden, Zeile nicht gefunden usw.
|
AVG_PARTICIPANTS |
FLOAT64 |
Durchschnittliche Anzahl der Teilnehmer an jedem Commit-Versuch. Weitere Informationen zu Teilnehmern finden Sie unter Lebensdauer von Spanner-Lese- und -Schreibvorgängen. |
AVG_TOTAL_LATENCY_SECONDS |
FLOAT64 |
Durchschnittliche Anzahl der Sekunden, die vom ersten Vorgang der Transaktion bis zum Commit/Abbruch benötigt wurden. |
AVG_COMMIT_LATENCY_SECONDS |
FLOAT64 |
Durchschnittliche Anzahl der Sekunden, die für die Ausführung des Commit-Vorgangs benötigt werden. |
AVG_BYTES |
FLOAT64 |
Durchschnittliche Anzahl der von der Transaktion geschriebenen Byte. |
TOTAL_LATENCY_DISTRIBUTION |
ARRAY<STRUCT>
|
Ein Histogramm der gesamten Commit-Latenz, d. h. die Zeit von der Startzeit des ersten Transaktionsvorgangs bis zum Commit- oder Abbruchzeitpunkt für alle Versuche einer Transaktion.
Wenn eine Transaktion mehrmals abgebrochen wird und dann der Commit erfolgreich ist, wird die Latenz für jeden Versuch bis zum endgültigen erfolgreichen Commit gemessen. Die Werte werden in Sekunden gemessen.
Das Array enthält ein einzelnes Element und hat den folgenden Typ:
Verwenden Sie die Funktion Weitere Informationen finden Sie unter Perzentil und Messwerte mit Verteilungsmesswerten. |
OPERATIONS_BY_TABLE |
ARRAY<STRUCT> |
Auswirkungen von
Mithilfe dieser Spalte können Sie die Auslastung von Tabellen visualisieren und Informationen zur Rate abrufen, mit der eine Transaktion in Tabellen schreibt.
Geben Sie das Array so an:
|
1 _exists
ist ein internes Feld, mit dem geprüft wird, ob eine bestimmte Zeile vorhanden ist.
Beispielabfragen
Dieser Abschnitt enthält mehrere Beispiel-SQL-Anweisungen zum Abrufen von Transaktionsstatistiken. Sie können diese SQL-Anweisungen mit den Clientbibliotheken, dem gcloud Spanner oder der Google Cloud Console ausführen.
Grundlegende Statistiken für jede Transaktion in einem bestimmten Zeitraum auflisten
Die folgende Abfrage gibt die Rohdaten für die Top-Transaktionen in der vorherigen Minute zurück.
SELECT fprint,
read_columns,
write_constructive_columns,
write_delete_tables,
avg_total_latency_seconds,
avg_commit_latency_seconds,
operations_by_table,
avg_bytes
FROM spanner_sys.txn_stats_top_minute
WHERE interval_end =
(SELECT MAX(interval_end)
FROM spanner_sys.txn_stats_top_minute);
Ausgabe der Abfrage
fprint | read_columns | write_constructive_columns | write_delete_tables | avg_total_latency_seconds | avg_commit_latency_seconds | operations_by_table | avg_bytes |
---|---|---|---|---|---|---|---|
40015598317 |
[] |
["Routes.name", "Cars.model"] |
["Users"] |
0.006578737 |
0.006547737 |
[["Cars",1107,30996],["Routes",560,26880]] |
25286 |
20524969030 |
["id", "no"] |
[] |
[] |
0.001732442 |
0.000247442 |
[] |
0 |
77848338483 |
[] |
[] |
["Cars", "Routes"] |
0.033467418 |
0.000251418 |
[] |
0 |
Transaktionen mit der höchsten durchschnittlichen Commit-Latenz auflisten
Die folgende Abfrage gibt die Transaktionen mit hoher durchschnittlicher Commit-Latenz in der vorherigen Stunde zurück, sortiert nach der höchsten bis niedrigsten durchschnittlichen Commit-Latenz.
SELECT fprint,
read_columns,
write_constructive_columns,
write_delete_tables,
avg_total_latency_seconds,
avg_commit_latency_seconds,
avg_bytes
FROM spanner_sys.txn_stats_top_hour
WHERE interval_end =
(SELECT MAX(interval_end)
FROM spanner_sys.txn_stats_top_hour)
ORDER BY avg_commit_latency_seconds DESC;
Ausgabe der Abfrage
fprint | read_columns | write_constructive_columns | write_delete_tables | avg_total_latency_seconds | avg_commit_latency_seconds | avg_bytes |
---|---|---|---|---|---|---|
40015598317 |
[] |
["Routes.name", "Cars.model"] |
["Users"] |
0.006578737 |
0.006547737 |
25286 |
77848338483 |
[] |
[] |
["Cars", "Routes"] |
0.033467418 |
0.000251418 |
0 |
20524969030 |
["id", "no"] |
[] |
[] |
0.001732442 |
0.000247442 |
0 |
Durchschnittliche Latenz von Transaktionen ermitteln, die bestimmte Spalten lesen
Die folgende Abfrage gibt die durchschnittlichen Latenzinformationen für Transaktionen zurück, die die Spalte ADDRESS aus 1-Stunden-Statistiken lesen:
SELECT fprint,
read_columns,
write_constructive_columns,
write_delete_tables,
avg_total_latency_seconds
FROM spanner_sys.txn_stats_top_hour
WHERE 'ADDRESS' IN UNNEST(read_columns)
ORDER BY avg_total_latency_seconds DESC;
Ausgabe der Abfrage
fprint | read_columns | write_constructive_columns | write_delete_tables | avg_total_latency_seconds |
---|---|---|---|---|
77848338483 |
["ID", "ADDRESS"] |
[] |
["Cars", "Routes"] |
0.033467418 |
40015598317 |
["ID", "NAME", "ADDRESS"] |
[] |
["Users"] |
0.006578737 |
Transaktionen nach der durchschnittlichen Anzahl der geänderten Byte auflisten
Die folgende Abfrage gibt die Transaktionen der letzten Stunde zurück, sortiert nach der durchschnittlichen Anzahl der von der Transaktion geänderten Byte.
SELECT fprint,
read_columns,
write_constructive_columns,
write_delete_tables,
avg_bytes
FROM spanner_sys.txn_stats_top_hour
ORDER BY avg_bytes DESC;
Ausgabe der Abfrage
fprint | read_columns | write_constructive_columns | write_delete_tables | avg_bytes |
---|---|---|---|---|
40015598317 |
[] |
[] |
["Users"] |
25286 |
77848338483 |
[] |
[] |
["Cars", "Routes"] |
12005 |
20524969030 |
["ID", "ADDRESS"] |
[] |
["Users"] |
10923 |
Zusammengefasste Statistiken
SPANNER_SYS
enthält auch Tabellen zum Speichern aggregierter Daten für alle Transaktionen, für die Spanner Statistiken in einem bestimmten Zeitraum erfasst hat:
SPANNER_SYS.TXN_STATS_TOTAL_MINUTE
: Zusammengefasste Statistiken für alle Transaktionen in Intervallen von einer MinuteSPANNER_SYS.TXN_STATS_TOTAL_10MINUTE
: Zusammengefasste Statistiken für alle Transaktionen in Intervallen von 10 MinutenSPANNER_SYS.TXN_STATS_TOTAL_HOUR
: Zusammengefasste Statistiken für alle Transaktionen in Intervallen von einer Stunde
Zusammengefasste Statistiktabellen haben die folgenden Eigenschaften:
Jede Tabelle enthält Daten für nicht überlappende Zeitintervalle in der Länge, die der Tabellenname angibt.
Die Intervalle basieren auf der Uhrzeit. 1-Minuten-Intervalle enden jeweils zur vollen Minute, 10-Minuten-Intervalle enden alle 10 Minuten ab der vollen Stunde und 1-Stunden-Intervalle enden zur vollen Stunde.
Beispielsweise sind um 11:59:30 Uhr die letzten Intervalle für SQL-Abfragen zu zusammengefassten Transaktionsstatistiken verfügbar:
- 1 Minute: 11:58:00–11:58:59 Uhr
- 10 Minuten: 11:40:00–11:49:59 Uhr
- 1 Stunde: 10:00:00–10:59:59 Uhr
Jede Zeile enthält zusammengefasste Statistiken für alle Transaktionen, die während des angegebenen Intervalls über die Datenbank ausgeführt wurden. Es gibt nur je eine Zeile pro Zeitintervall.
Die in den
SPANNER_SYS.TXN_STATS_TOTAL_*
-Tabellen erfassten Statistiken können Transaktionen enthalten, die Spanner nicht in denSPANNER_SYS.TXN_STATS_TOP_*
-Tabellen erfasst hat.Einige Spalten in diesen Tabellen werden in Cloud Monitoring als Messwerte angezeigt. Die exponierten Messwerte sind:
- Anzahl der Commit-Versuche
- Anzahl der Commit-Wiederholungen
- Transaktionsteilnehmer
- Transaktionslatenzen
- Geschriebene Byte
Weitere Informationen finden Sie unter Spanner-Messwerte.
Tabellenschema
Spaltenname | Typ | Beschreibung |
---|---|---|
INTERVAL_END |
TIMESTAMP |
Ende des Zeitintervalls, in dem diese Statistik erfasst wurde. |
ATTEMPT_COUNT |
INT64 |
Gesamtzahl der Transaktionsversuche, einschließlich der Versuche, die vor dem Aufruf von „commit“ abgebrochen werden. |
COMMIT_ATTEMPT_COUNT |
INT64 |
Gesamtzahl der Commit-Transaktionsversuche. Sie muss mit der Anzahl der Aufrufe der commit -Methode der Transaktion übereinstimmen.
|
COMMIT_ABORT_COUNT |
INT64 |
Gesamtzahl der abgebrochenen Transaktionsversuche, einschließlich der abgebrochenen Transaktionsversuche vor dem Aufruf der Methode commit der Transaktion. |
COMMIT_RETRY_COUNT |
INT64 |
Anzahl der Commit-Versuche, die Wiederholungsversuche aus zuvor abgebrochenen Versuchen sind. Eine Spanner-Transaktion wurde möglicherweise aufgrund von Sperrenkonflikten oder vorübergehenden Ereignissen mehrmals ausprobiert, bevor der Commit durchgeführt wird. Eine hohe Anzahl von Wiederholungsversuchen im Verhältnis zu Commit-Versuchen deutet auf Probleme hin, die untersucht werden sollten. Weitere Informationen finden Sie unter Transaktionen und Commit-Zählungen auf dieser Seite. |
COMMIT_FAILED_PRECONDITION_COUNT |
INT64 |
Gesamtzahl der Commit-Transaktionsversuche, bei denen fehlgeschlagene Vorbedingungsfehler zurückgegeben wurden, z. B. UNIQUE -Indexverstöße, Zeile ist bereits vorhanden, Zeile nicht gefunden usw.
|
AVG_PARTICIPANTS |
FLOAT64 |
Durchschnittliche Anzahl der Teilnehmer an jedem Commit-Versuch. Weitere Informationen zu Teilnehmern finden Sie unter Lebensdauer von Spanner-Lese- und -Schreibvorgängen. |
AVG_TOTAL_LATENCY_SECONDS |
FLOAT64 |
Durchschnittliche Anzahl der Sekunden, die vom ersten Vorgang der Transaktion bis zum Commit/Abbruch benötigt wurden. |
AVG_COMMIT_LATENCY_SECONDS |
FLOAT64 |
Durchschnittliche Anzahl der Sekunden, die für die Ausführung des Commit-Vorgangs benötigt werden. |
AVG_BYTES |
FLOAT64 |
Durchschnittliche Anzahl der von der Transaktion geschriebenen Byte. |
TOTAL_LATENCY_DISTRIBUTION |
ARRAY<STRUCT>
|
Ein Histogramm der gesamten Commit-Latenz, also die Zeit vom Beginn des ersten Transaktionsvorgangs bis zur Commit- oder Abbruchzeit für alle Transaktionsversuche.
Wenn eine Transaktion mehrmals abgebrochen wird und dann ein erfolgreicher Commit durchgeführt wird, wird die Latenz für jeden Versuch bis zum endgültigen erfolgreichen Commit gemessen. Die Werte werden in Sekunden gemessen.
Das Array enthält ein einzelnes Element und hat den folgenden Typ:
Verwenden Sie die Funktion Weitere Informationen finden Sie unter Perzentil und Messwerte mit Verteilungsmesswerten. |
OPERATIONS_BY_TABLE |
ARRAY<STRUCT> |
Auswirkungen von
Diese Spalte hilft Ihnen, die Auslastung von Tabellen zu visualisieren, und bietet einen Überblick über die Geschwindigkeit, mit der Transaktionen in Tabellen schreiben.
Geben Sie das Array so an:
|
Beispielabfragen
Dieser Abschnitt enthält mehrere Beispiel-SQL-Anweisungen zum Abrufen von Transaktionsstatistiken. Sie können diese SQL-Anweisungen mit den Clientbibliotheken, dem gcloud Spanner oder der Google Cloud Console ausführen.
Gesamtzahl der Commit-Versuche für eine Transaktion ermitteln
Die folgende Abfrage gibt die Gesamtzahl der Commit-Versuche für alle Transaktionen im letzten vollständigen Intervall von einer Minute zurück:
SELECT interval_end,
commit_attempt_count
FROM spanner_sys.txn_stats_total_minute
WHERE interval_end =
(SELECT MAX(interval_end)
FROM spanner_sys.txn_stats_total_minute)
ORDER BY interval_end;
Ausgabe der Abfrage
interval_end | commit_attempt_count |
---|---|
2020-01-17 11:46:00-08:00 |
21 |
Beachten Sie, dass das Ergebnis nur eine Zeile enthält, da zusammengefasste Statistiken nur einen Eintrag pro interval_end
für einen beliebigen Zeitraum enthalten.
Gesamte Commit-Latenz für alle Transaktionen ermitteln
Die folgende Abfrage gibt die gesamte Commit-Latenz für alle Transaktionen in den letzten 10 Minuten zurück:
SELECT (avg_commit_latency_seconds * commit_attempt_count / 60 / 60)
AS total_commit_latency_hours
FROM spanner_sys.txn_stats_total_10minute
WHERE interval_end =
(SELECT MAX(interval_end)
FROM spanner_sys.txn_stats_total_10minute);
Ausgabe der Abfrage
total_commit_latency_hours |
---|
0.8967 |
Beachten Sie, dass das Ergebnis nur eine Zeile enthält, da zusammengefasste Statistiken nur einen Eintrag pro interval_end
für einen beliebigen Zeitraum enthalten.
Latenz des 99. Perzentils für Transaktionen ermitteln
Die folgende Abfrage gibt die Latenz des 99. Perzentils für Transaktionen zurück, die in den letzten 10 Minuten ausgeführt wurden:
SELECT interval_end, avg_total_latency_seconds,
SPANNER_SYS.DISTRIBUTION_PERCENTILE(total_latency_distribution[OFFSET(0)], 99.0)
AS percentile_latency
FROM spanner_sys.txn_stats_total_10minute
WHERE interval_end =
(SELECT MAX(interval_end)
FROM spanner_sys.txn_stats_total_10minute)
ORDER BY interval_end;
Screenshot: Ausgabe der Abfrage
interval_end | avg_total_latency_seconds | percentile_latency |
---|---|---|
2022-08-17 11:46:00-08:00 |
0.34576998305986395 |
9.00296190476190476 |
Beachten Sie den großen Unterschied zwischen der durchschnittlichen und der 99. Perzentillatenz. Die Latenz des 99. Perzentils hilft bei der Identifizierung möglicher Ausreißertransaktionen mit hoher Latenz.
Das Ergebnis enthält nur eine Zeile, da aggregierte Statistiken für einen bestimmten Zeitraum nur einen Eintrag pro interval_end
enthalten.
Datenaufbewahrung
Spanner speichert die Daten für jede Tabelle mindestens für die folgenden Zeiträume:
SPANNER_SYS.TXN_STATS_TOP_MINUTE
undSPANNER_SYS.TXN_STATS_TOTAL_MINUTE
: Intervalle der letzten 6 Stunden.SPANNER_SYS.TXN_STATS_TOP_10MINUTE
undSPANNER_SYS.TXN_STATS_TOTAL_10MINUTE
: Intervalle der letzten 4 Tage.SPANNER_SYS.TXN_STATS_TOP_HOUR
undSPANNER_SYS.TXN_STATS_TOTAL_HOUR
: Intervalle der letzten 30 Tage.
Transaktionsstatistiken in Spanner geben Aufschluss darüber, wie eine Anwendung die Datenbank verwendet. Sie sind bei der Untersuchung von Leistungsproblemen hilfreich. Sie können beispielsweise überprüfen, ob langsam laufende Transaktionen zu Konflikten führen, oder Sie können potenzielle Quellen mit hoher Auslastung identifizieren, z. B. große Aktualisierungsvolumen für eine bestimmte Spalte. Mit den folgenden Schritten zeigen wir Ihnen, wie Sie mithilfe von Transaktionsstatistiken Einsprüche in Ihrer Datenbank untersuchen.
Transaktionen und Commit-Anzahl verstehen
Eine Spanner-Transaktion muss möglicherweise mehrmals ausprobiert werden, bevor sie übergeben wird. Dies kann dann der Fall sein, wenn zwei Transaktionen versuchen, gleichzeitig mit denselben Daten zu arbeiten, und eine der Transaktionen abgebrochen werden muss, um das Isolationsattribut beizubehalten. Die folgenden vorübergehenden Ereignisse können ebenfalls zum Abbruch einer Transaktion führen:
Vorübergehende Netzwerkprobleme.
Änderungen des Datenbankschemas, die angewendet werden, während eine Transaktion gerade mit Commit ausgeführt wird.
Die Spanner-Instanz hat nicht die Kapazität, alle eingehenden Anfragen zu verarbeiten.
In solchen Szenarien sollte ein Client die abgebrochene Transaktion wiederholen, bis sie erfolgreich mit Commit ausgeführt wird oder eine Zeitüberschreitung eintritt. Für Nutzer der offiziellen Spanner-Clientbibliotheken wurde in jeder Bibliothek ein automatischer Mechanismus für Wiederholungen implementiert. Wenn Sie eine benutzerdefinierte Version des Clientcodes verwenden, bündeln Sie Ihre Transaktions-Commits in einer Wiederholungsschleife.
Eine Spanner-Transaktion kann auch aufgrund eines nicht wiederholbaren Fehlers wie einer Zeitüberschreitung bei der Transaktion, Berechtigungsproblemen oder einem ungültigen Tabellen-/Spaltennamen abgebrochen werden. Solche Transaktionen müssen nicht wiederholt werden. Die Spanner-Clientbibliothek gibt den Fehler sofort zurück.
In der folgenden Tabelle werden einige Beispiele dafür gezeigt, wie COMMIT_ATTEMPT_COUNT
, COMMIT_ABORT_COUNT
und COMMIT_RETRY_COUNT
in verschiedenen Szenarien geloggt werden.
Szenario | COMMIT_ATTEMPT_COUNT | COMMIT_ABORT_COUNT | COMMIT_RETRY_COUNT |
---|---|---|---|
Transaktion wurde beim ersten Versuch erfolgreich mit Commit ausgeführt. | 1 | 0 | 0 |
Transaktion aufgrund eines Zeitüberschreitungsfehlers abgebrochen. | 1 | 1 | 0 |
Transaktion wurde aufgrund eines vorübergehenden Netzwerkproblems abgebrochen und nach einem erneuten Versuch erfolgreich mit Commit ausgeführt. | 2 | 1 | 1 |
5 Transaktionen mit demselben FPRINT werden innerhalb eines 10-Minuten-Intervalls ausgeführt. 3 der Transaktionen wurden beim ersten Versuch erfolgreich mit Commit ausgeführt, während 2 Transaktionen abgebrochen und dann beim ersten Wiederholungsversuch erfolgreich mit Commit ausgeführt wurden. | 7 | 2 | 2 |
Die Daten in den Tabellen mit den Transaktionsstatistiken sind zusammengefasste Daten für ein Zeitintervall. Für ein bestimmtes Intervall ist es möglich, dass eine Transaktion abgebrochen und wiederholt wird und in verschiedene Buckets fällt. Daher stimmen Abbrüche und Wiederholungsversuche in einem bestimmten Zeitintervall möglicherweise nicht überein.
Diese Statistiken dienen der Fehlerbehebung und Selbstprüfung und sind nicht zu 100% genau. Statistiken werden im Arbeitsspeicher aggregiert, bevor sie in Spanner-Tabellen gespeichert werden. Während eines Upgrades oder anderer Wartungsaktivitäten können Spanner-Server neu gestartet werden, was die Genauigkeit der Zahlen beeinträchtigt.
Datenbankkonflikte mithilfe von Transaktionsstatistiken beheben
Mit SQL-Code oder dem Dashboard Transaktionsinformationen können Sie die Transaktionen in Ihrer Datenbank ansehen, die aufgrund von Sperrenkonflikten zu hohen Latenzen führen können.
In den folgenden Abschnitten wird gezeigt, wie Sie solche Transaktionen mithilfe von SQL-Code untersuchen können.
Zeitraum für die Untersuchung auswählen
Sie finden diese in der Anwendung, die Spanner verwendet.
Beispiel: Das Problem tritt am 17. Mai 2020 gegen 17:20 Uhr auf.
Sie können Transaktions-Tags verwenden, um die Quelle der Transaktion zu ermitteln, und für eine effektive Fehlerbehebung bei Sperrenkonflikten zwischen der Transaktionsstatistiktabelle und den Sperrstatistiktabellen korrelieren. Weitere Informationen finden Sie unter Fehlerbehebung bei Transaktions-Tags.
Transaktionsstatistiken für den ausgewählten Zeitraum erfassen
Um unsere Untersuchung zu starten, fragen wir die Tabelle TXN_STATS_TOTAL_10MINUTE
um den Beginn des Problems ab. Die Ergebnisse dieser Abfrage zeigen, wie sich die Latenz und andere Transaktionsstatistiken in diesem Zeitraum verändert haben.
Die folgende Abfrage gibt beispielsweise die aggregierten Transaktionsstatistiken von 4:30 pm
bis 7:40 pm
(einschließlich) zurück.
SELECT
interval_end,
ROUND(avg_total_latency_seconds,4) as avg_total_latency_seconds,
commit_attempt_count,
commit_abort_count
FROM SPANNER_SYS.TXN_STATS_TOTAL_10MINUTE
WHERE
interval_end >= "2020-05-17T16:40:00"
AND interval_end <= "2020-05-17T19:40:00"
ORDER BY interval_end;
Die folgende Tabelle enthält Beispieldaten, die von unserer Abfrage zurückgegeben wurden.
interval_end | avg_total_latency_seconds | commit_attempt_count | commit_abort_count |
---|---|---|---|
2020-05-17 16:40:00-07:00 | 0.0284 | 315691 | 5170 |
2020-05-17 16:50:00-07:00 | 0.0250 | 302124 | 3828 |
2020-05-17 17:00:00-07:00 | 0.0460 | 346087 | 11382 |
2020-05-17 17:10:00-07:00 | 0.0864 | 379964 | 33826 |
2020-05-17 17:20:00-07:00 | 0.1291 | 390343 | 52549 |
2020-05-17 17:30:00-07:00 | 0.1314 | 456455 | 76392 |
2020-05-17 17:40:00-07:00 | 0.1598 | 507774 | 121458 |
2020-05-17 17:50:00-07:00 | 0.1641 | 516587 | 115875 |
2020-05-17 18:00:00-07:00 | 0.1578 | 552711 | 122626 |
2020-05-17 18:10:00-07:00 | 0.1750 | 569460 | 154205 |
2020-05-17 18:20:00-07:00 | 0.1727 | 613571 | 160772 |
2020-05-17 18:30:00-07:00 | 0.1588 | 601994 | 143044 |
2020-05-17 18:40:00-07:00 | 0.2025 | 604211 | 170019 |
2020-05-17 18:50:00-07:00 | 0.1615 | 601622 | 135601 |
2020-05-17 19:00:00-07:00 | 0.1653 | 596804 | 129511 |
2020-05-17 19:10:00-07:00 | 0.1414 | 560023 | 112247 |
2020-05-17 19:20:00-07:00 | 0.1367 | 570864 | 100596 |
2020-05-17 19:30:00-07:00 | 0.0894 | 539729 | 65316 |
2020-05-17 19:40:00-07:00 | 0.0820 | 479151 | 40398 |
Hier sehen Sie, dass die aggregierte Latenz und die Anzahl der Abbrüche in den hervorgehobenen Zeiträumen höher sind. Sie können ein Intervall von 10 Minuten auswählen, in dem die zusammengefasste Latenz und/oder die Zahl der abgebrochenen Instanzen hoch ist. Wir wählen das Intervall aus, das auf 2020-05-17T18:40:00
endet, und verwenden es im nächsten Schritt, um zu ermitteln, welche Transaktionen zu einer hohen Latenz und einer hohen Anzahl von Abbrüchen beitragen.
Transaktionen mit hoher Latenz identifizieren
Lassen Sie uns nun die Tabelle TXN_STATS_TOP_10MINUTE
nach dem Intervall abfragen, das im vorherigen Schritt ausgewählt wurde. Anhand dieser Daten können wir erkennen, welche Transaktionen eine hohe Latenz und/oder eine hohe Anzahl von Abbrüchen aufweisen.
Führen Sie die folgende Abfrage aus, um die Transaktionen mit hoher Leistung in absteigender Reihenfolge der Gesamtlatenz für unser Beispielintervall mit der Endung 2020-05-17T18:40:00
zu erhalten.
SELECT
interval_end,
fprint,
ROUND(avg_total_latency_seconds,4) as avg_total_latency_seconds,
ROUND(avg_commit_latency_seconds,4) as avg_commit_latency_seconds,
commit_attempt_count,
commit_abort_count,
commit_retry_count
FROM SPANNER_SYS.TXN_STATS_TOP_10MINUTE
WHERE
interval_end = "2020-05-17T18:40:00"
ORDER BY avg_total_latency_seconds DESC;
interval_end | fprint | avg_total_latency_seconds | avg_commit_latency_seconds | commit_attempt_count | commit_abort_count | commit_retry_count |
---|---|---|---|---|---|---|
2020-05-17 18:40:00-07:00 | 15185072816865185658 | 0.3508 | 0.0139 | 278802 | 142205 | 129884 |
2020-05-17 18:40:00-07:00 | 15435530087434255496 | 0.1633 | 0.0142 | 129012 | 27177 | 24559 |
2020-05-17 18:40:00-07:00 | 14175643543447671202 | 0.1423 | 0.0133 | 5357 | 636 | 433 |
2020-05-17 18:40:00-07:00 | 898069986622520747 | 0.0198 | 0.0158 | 6 | 0 | 0 |
2020-05-17 18:40:00-07:00 | 10510121182038036893 | 0.0168 | 0.0125 | 7 | 0 | 0 |
2020-05-17 18:40:00-07:00 | 9287748709638024175 | 0.0159 | 0.0118 | 4269 | 1 | 0 |
2020-05-17 18:40:00-07:00 | 7129109266372596045 | 0.0142 | 0.0102 | 182227 | 0 | 0 |
2020-05-17 18:40:00-07:00 | 15630228555662391800 | 0.0120 | 0.0107 | 58 | 0 | 0 |
2020-05-17 18:40:00-07:00 | 7907238229716746451 | 0.0108 | 0.0097 | 65 | 0 | 0 |
2020-05-17 18:40:00-07:00 | 10158167220149989178 | 0.0095 | 0.0047 | 3454 | 0 | 0 |
2020-05-17 18:40:00-07:00 | 9353100217060788102 | 0.0093 | 0.0045 | 725 | 0 | 0 |
2020-05-17 18:40:00-07:00 | 9521689070912159706 | 0.0093 | 0.0045 | 164 | 0 | 0 |
2020-05-17 18:40:00-07:00 | 11079878968512225881 | 0.0064 | 0.0019 | 65 | 0 | 0 |
Wir sehen deutlich, dass die erste Zeile (hervorgehoben) in der vorherigen Tabelle eine Transaktion mit hoher Latenz aufgrund einer hohen Anzahl von Commit-Abbrüchen zeigt. Wir sehen auch eine hohe Anzahl von Commit-Wiederholungsversuchen, die darauf hinweisen, dass die abgebrochenen Commits anschließend wiederholt wurden. Im nächsten Schritt untersuchen wir das Problem, um die Ursache zu ermitteln.
Identifizieren Sie die an einer Transaktion beteiligten Spalten mit hoher Latenz
In diesem Schritt prüfen wir, ob Transaktionen mit hoher Latenz für denselben Spaltensatz ausgeführt werden. Dazu werden read_columns
-, write_constructive_columns
- und write_delete_tables
-Daten für Transaktionen mit hoher Abbruchrate abgerufen. Der Wert FPRINT
ist auch im nächsten Schritt hilfreich.
SELECT
fprint,
read_columns,
write_constructive_columns,
write_delete_tables
FROM SPANNER_SYS.TXN_STATS_TOP_10MINUTE
WHERE
interval_end = "2020-05-17T18:40:00"
ORDER BY avg_total_latency_seconds DESC LIMIT 3;
fprint | read_columns | write_constructive_columns | write_delete_tables |
---|---|---|---|
15185072816865185658 | [TestHigherLatency._exists,TestHigherLatency.lang_status,TestHigherLatency.score,globalTagAffinity.shares] |
[TestHigherLatency._exists,TestHigherLatency.shares,TestHigherLatency_lang_status_score_index.shares] |
[] |
15435530087434255496 | [TestHigherLatency._exists,TestHigherLatency.lang_status,TestHigherLatency.likes,globalTagAffinity.score] |
[TestHigherLatency._exists,TestHigherLatency.likes,TestHigherLatency_lang_status_score_index.likes] |
[] |
14175643543447671202 | [TestHigherLatency._exists,TestHigherLatency.lang_status,TestHigherLatency.score,globalTagAffinity.ugcCount] |
[TestHigherLatency._exists,TestHigherLatency.ugcCount,TestHigherLatency_lang_status_score_index.ugcCount] |
[] |
Wie die Ausgabe in der vorherigen Tabelle zeigt, lesen die Transaktionen mit der höchsten durchschnittlichen Gesamtlatenz dieselben Spalten. Wir können auch Schreibkonflikte beobachten, da die Transaktionen in dieselbe Spalte schreiben, d. H. TestHigherLatency._exists
.
Ermitteln, wie sich die Transaktionsleistung im Laufe der Zeit verändert hat
Wir können sehen, wie sich die mit dieser Transaktionsform verknüpften Statistiken im Laufe der Zeit verändert haben. Verwenden Sie die folgende Abfrage, wobei $FPRINT der Fingerabdruck der Transaktion mit hoher Latenz aus dem vorherigen Schritt ist.
SELECT
interval_end,
ROUND(avg_total_latency_seconds, 3) AS latency,
ROUND(avg_commit_latency_seconds, 3) AS commit_latency,
commit_attempt_count,
commit_abort_count,
commit_retry_count,
commit_failed_precondition_count,
avg_bytes
FROM SPANNER_SYS.TXN_STATS_TOP_10MINUTE
WHERE
interval_end >= "2020-05-17T16:40:00"
AND interval_end <= "2020-05-17T19:40:00"
AND fprint = $FPRINT
ORDER BY interval_end;
interval_end | Latenz | commit_latency | commit_attempt_count | commit_abort_count | commit_retry_count | commit_failed_precondition_count | avg_bytes |
---|---|---|---|---|---|---|---|
2020-05-17 16:40:00-07:00 | 0.095 | 0.010 | 53230 | 4752 | 4330 | 0 | 91 |
2020-05-17 16:50:00-07:00 | 0.069 | 0.009 | 61264 | 3589 | 3364 | 0 | 91 |
2020-05-17 17:00:00-07:00 | 0.150 | 0.010 | 75868 | 10557 | 9322 | 0 | 91 |
2020-05-17 17:10:00-07:00 | 0.248 | 0.013 | 103151 | 30220 | 28483 | 0 | 91 |
2020-05-17 17:20:00-07:00 | 0.310 | 0.012 | 130078 | 45655 | 41966 | 0 | 91 |
2020-05-17 17:30:00-07:00 | 0.294 | 0.012 | 160064 | 64930 | 59933 | 0 | 91 |
2020-05-17 17:40:00-07:00 | 0.315 | 0.013 | 209614 | 104949 | 96770 | 0 | 91 |
2020-05-17 17:50:00-07:00 | 0.322 | 0.012 | 215682 | 100408 | 95867 | 0 | 90 |
2020-05-17 18:00:00-07:00 | 0.310 | 0.012 | 230932 | 106728 | 99462 | 0 | 91 |
2020-05-17 18:10:00-07:00 | 0.309 | 0.012 | 259645 | 131049 | 125889 | 0 | 91 |
2020-05-17 18:20:00-07:00 | 0.315 | 0.013 | 272171 | 137910 | 129411 | 0 | 90 |
2020-05-17 18:30:00-07:00 | 0.292 | 0.013 | 258944 | 121475 | 115844 | 0 | 91 |
2020-05-17 18:40:00-07:00 | 0.350 | 0.013 | 278802 | 142205 | 134229 | 0 | 91 |
2020-05-17 18:50:00-07:00 | 0.302 | 0.013 | 256259 | 115626 | 109756 | 0 | 91 |
2020-05-17 19:00:00-07:00 | 0.315 | 0.014 | 250560 | 110662 | 100322 | 0 | 91 |
2020-05-17 19:10:00-07:00 | 0.271 | 0.014 | 238384 | 99025 | 90187 | 0 | 91 |
2020-05-17 19:20:00-07:00 | 0.273 | 0.014 | 219687 | 84019 | 79874 | 0 | 91 |
2020-05-17 19:30:00-07:00 | 0,198 | 0.013 | 195357 | 59370 | 55909 | 0 | 91 |
2020-05-17 19:40:00-07:00 | 0.181 | 0.013 | 167514 | 35705 | 32885 | 0 | 91 |
In der obigen Ausgabe können wir sehen, dass die Gesamtlatenz für den hervorgehobenen Zeitraum hoch ist. Und wenn die Gesamtlatenz hoch ist, sind sowohl commit_attempt_count
,commit_abort_count
als auch commit_retry_count
auch hoch, obwohl sich die Commit-Latenz (commit_latency
) nicht wesentlich geändert hat. Da Transaktions-Commits häufiger abgebrochen werden, sind Commit-Versuche aufgrund von Commit-Wiederholungen ebenfalls hoch.
Fazit
In diesem Beispiel haben wir festgestellt, dass die Anzahl der hohen Commit-Abbrüche die Ursache für hohe Latenz war. Der nächste Schritt besteht darin, die von der Anwendung empfangenen Commit-Abbruchfehlermeldungen zu überprüfen, um den Grund für den Abbruch zu ermitteln. Durch die Überprüfung von Logs in der Anwendung sehen wir, dass die Anwendung während dieser Zeit ihre Arbeitslast geändert hat, d.H. Eine andere Transaktionsform mit hohem attempts_per_second
angezeigt wurde und diese andere Transaktion (möglicherweise ein nächtlicher Bereinigungsjob) für die zusätzliche Sperre verantwortlich war in Konflikt geraten.
Transaktionen identifizieren, die nicht korrekt wiederholt wurden
Die folgende Abfrage gibt die Transaktionen der letzten zehn Minuten zurück, die eine hohe Anzahl von Commit-Abbrüchen haben, aber keine Wiederholungsversuche.
SELECT
*
FROM (
SELECT
fprint,
SUM(commit_attempt_count) AS total_commit_attempt_count,
SUM(commit_abort_count) AS total_commit_abort_count,
SUM(commit_retry_count) AS total_commit_retry_count
FROM
SPANNER_SYS.TXN_STATS_TOP_10MINUTE
GROUP BY
fprint )
WHERE
total_commit_retry_count = 0
AND total_commit_abort_count > 0
ORDER BY
total_commit_abort_count DESC;
fprint | total_commit_attempt_count | total_commit_abort_count | total_commit_retry_count |
---|---|---|---|
1557557373282541312 | 3367894 | 44232 | 0 |
5776062322886969344 | 13566 | 14 | 0 |
Wir können sehen, dass die Transaktion mit fprint 1557557373282541312 44.232 Mal abgebrochen, aber nie wiederholt wurde. Das sieht verdächtig aus, da die Anzahl der Abbruchvorgänge hoch ist und es unwahrscheinlich ist, dass jeder Abbruch durch einen Fehler verursacht wurde, der nicht wiederholt werden kann. Auf der anderen Seite ist die Transaktion mit dem fprint 5776062322886969344 weniger verdächtig, da die Gesamtzahl der Abbruchvorgänge nicht so hoch ist.
Die folgende Abfrage gibt weitere Details zur Transaktion mit fprint 1557557373282541312 zurück, einschließlich read_columns
, write_constructive_columns
und write_delete_tables
. Diese Informationen helfen dabei, die Transaktion im Clientcode zu identifizieren, wo die Wiederholungslogik für dieses Szenario geprüft werden kann.
SELECT
interval_end,
fprint,
read_columns,
write_constructive_columns,
write_delete_tables,
commit_attempt_count,
commit_abort_count,
commit_retry_count
FROM
SPANNER_SYS.TXN_STATS_TOP_10MINUTE
WHERE
fprint = 1557557373282541312
ORDER BY
interval_end DESC;
interval_end | fprint | read_columns | write_constructive_columns | write_delete_tables | commit_attempt_count | commit_abort_count | commit_retry_count |
---|---|---|---|---|---|---|---|
2021-01-27T18:30:00Z | 1557557373282541312 | ['Singers._exists'] | ['Singers.FirstName', 'Singers.LastName', 'Singers._exists'] | [] | 805228 | 1839 | 0 |
2021-01-27T18:20:00Z | 1557557373282541312 | ['Singers._exists'] | ['Singers.FirstName', 'Singers.LastName', 'Singers._exists'] | [] | 1034429 | 38779 | 0 |
2021-01-27T18:10:00Z | 1557557373282541312 | ['Singers._exists'] | ['Singers.FirstName', 'Singers.LastName', 'Singers._exists'] | [] | 833677 | 2266 | 0 |
2021-01-27T18:00:00Z | 1557557373282541312 | ['Singers._exists'] | ['Singers.FirstName', 'Singers.LastName', 'Singers._exists'] | [] | 694560 | 1348 | 0 |
Wir sehen, dass die Transaktion einen Lesevorgang in die ausgeblendete Spalte Singers._exists
umfasst, um das Vorhandensein einer Zeile zu prüfen. Die Transaktion schreibt auch in die Spalten Singers.FirstName
und Singer.LastName
. Anhand dieser Informationen können Sie feststellen, ob der in Ihrer benutzerdefinierten Clientbibliothek implementierte Mechanismus für Transaktionswiederholungen wie erwartet funktioniert.
Nächste Schritte
- Weitere Informationen zu Tools zur Selbstbeobachtung
- Weitere Informationen zu anderen Informationen, die Spanner für jede Datenbank in den Informationsschematabellen der Datenbank speichert.
- Weitere Informationen zu SQL-Best Practices für Spanner
- Hohe CPU-Auslastung untersuchen