Transaktionsstatistiken

In diesem Dokument werden die Transaktionsstatistiken beschrieben, die Spanner als integrierte Tabellen bietet. Sie können Statistiken aus diesen SPANNER_SYS.TXN_STATS*-Tabellen mithilfe von SQL-Anweisungen abrufen.

Wann werden Transaktionsstatistiken verwendet?

Transaktionsstatistiken sind nützlich, um Leistungsprobleme zu untersuchen. Sie können beispielsweise prüfen, ob es langsam ausgeführte Transaktionen gibt, die sich auf die Leistung oder die Abfragen pro Sekunde (QPS) in Ihrer Datenbank auswirken könnten. Ein weiteres Szenario ist, wenn Ihre Clientanwendungen eine hohe Latenz bei der Transaktionsausführung aufweisen. Die Analyse von Transaktionsstatistiken kann helfen, potenzielle Engpässe zu erkennen, z. B. große Mengen an Aktualisierungen einer bestimmten Spalte, die sich auf die Latenz auswirken könnten.

Auf Transaktionsstatistiken zugreifen

Hinweis: Spanner Studio (früher in der Google Cloud Console als Abfrage bezeichnet) unterstützt SQL-, DML- und DDL-Vorgänge in einem einzigen Editor. Weitere Informationen finden Sie unter Daten mit der Google Cloud Console verwalten.

Spanner stellt die Tabelle mit den Transaktionsstatistiken im Schema SPANNER_SYS bereit. Sie können auf folgende Weise auf SPANNER_SYS-Daten zugreifen:

• Die Spanner Studio-Seite einer Datenbank in der Google Cloud Console.

• Befehl gcloud spanner databases execute-sql

• Das Dashboard Transaktionsstatistiken.

• Die Methode executeSql oder executeStreamingSql.

Die folgenden von Spanner bereitgestellten Methoden für einzelne Lesevorgänge unterstützen SPANNER_SYS nicht:

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

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, die über 1-minütige Intervalle aggregiert werden.

• SPANNER_SYS.TXN_STATS_TOP_10MINUTE: Transaktionsstatistiken, die in 10-Minuten-Intervallen zusammengefasst werden.

• SPANNER_SYS.TXN_STATS_TOP_HOUR: Transaktionsstatistiken, die über einstündige Intervalle aggregiert werden.

Diese Tabellen haben folgende Attribute:

• Jede Tabelle enthält Daten für nicht überlappende Zeitintervalle der im Tabellennamen angegebenen Dauer.

• Intervalle basieren auf Uhrzeiten

  • Intervalle von 1 Minute enden zur vollen Minute.
  • 10-Minuten-Intervalle enden alle 10 Minuten ab der vollen Stunde.
  • 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 FPRINT (Fingerabdruck) der Transaktionen. Wenn ein Transaktions-Tag vorhanden ist, ist FPRINT der Hash des Tags. Andernfalls ist es der Hash, der anhand der an der Transaktion beteiligten Vorgänge berechnet wird.

• Da Statistiken nach FPRINT gruppiert werden, wird für eine Transaktion, die innerhalb eines Zeitintervalls mehrmals ausgeführt wird, nur ein Eintrag in diesen Tabellen angezeigt.

• Jede Zeile enthält Statistiken für alle Ausführungen einer bestimmten Transaktion, für die Cloud Spanner im angegebenen Intervall Statistiken erfasst.

• Wenn Spanner keine Statistiken für alle während des Intervalls ausgeführten Transaktionen in diesen Tabellen speichern kann, priorisiert das System Transaktionen mit der höchsten Latenz, den meisten Commit-Versuchen und den meisten geschriebenen Byte im angegebenen Intervall.

• Alle Spalten in den Tabellen können Nullwerte enthalten.

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 einzigen Zeile gruppiert, wobei „TRANSACTION_TAG“ mit diesem Tag-String übereinstimmt.
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>	Die Gruppe von Spalten, die von der Transaktion konstruktiv geschrieben, d. h. neuen Werten zugewiesen wurden. Wenn die Transaktion bei Änderungsstreams Schreibvorgänge in Spalten und Tabellen umfasst, die von einem Änderungsstream überwacht werden, enthält WRITE_CONSTRUCTIVE_COLUMNS zwei Spalten: .data und ._exists, denen ein Änderungsstreamname vorangestellt ist. _exists ist ein Feld, mit dem geprüft wird, ob eine bestimmte Zeile vorhanden ist oder nicht.
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 der Methode commit abgebrochen werden. Diese Anzahl entspricht der Gesamtzahl der Versuche im angegebenen Intervall. Weitere Informationen zu Intervallen finden Sie unter Intervalle.
COMMIT_ATTEMPT_COUNT	INT64	Gesamtzahl der Versuche, Transaktionen zu committen. Diese muss mit der Anzahl der Aufrufe der commit-Methode der Transaktion übereinstimmen. Diese Anzahl entspricht der Gesamtzahl der Commit-Versuche im angegebenen Intervall. Weitere Informationen zu Intervallen finden Sie unter Intervalle.
COMMIT_ABORT_COUNT	INT64	Gesamtzahl der Transaktionsversuche, die abgebrochen werden, einschließlich der Versuche, die vor dem Aufruf der Methode commit der Transaktion abgebrochen werden. Diese Zahl entspricht der Gesamtzahl der Abbrüche im angegebenen Zeitraum. Weitere Informationen zu Intervallen finden Sie unter Intervalle.
COMMIT_RETRY_COUNT	INT64	Gesamtzahl der Versuche, die Wiederholungen von zuvor abgebrochenen Versuchen sind. Eine Spanner-Transaktion kann aufgrund von Sperrkonflikten oder vorübergehenden Ereignissen mehrmals versucht werden, bevor sie festgeschrieben wird. Eine hohe Anzahl von Wiederholungsversuchen im Verhältnis zu Commit-Versuchen deutet darauf hin, dass es Probleme gibt, 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-Versuche für Transaktionen, die Fehler vom Typ „Fehlgeschlagene Vorbedingung“ zurückgegeben haben, z. B. UNIQUE-Indexverletzungen, Zeile bereits vorhanden oder Zeile nicht gefunden.
SERIALIZABLE_PESSIMISTIC_TXN_COUNT	INT64	Gesamtzahl der Transaktionsversuche, die mit der Isolationsstufe SERIALIZABLE und der Sperrung PESSIMISTIC initiiert wurden. Es ist eine Teilmenge von ATTEMPT_COUNT.
SERIALIZABLE_OPTIMISTIC_TXN_COUNT	INT64	Gesamtzahl der Transaktionsversuche, die mit der Isolationsstufe SERIALIZABLE und der OPTIMISTIC-Sperre initiiert wurden. Es ist eine Teilmenge von ATTEMPT_COUNT.
REPEATABLE_READ_OPTIMISTIC_TXN_COUNT	INT64	Gesamtzahl der Transaktionsversuche, die mit der Isolationsstufe REPEATABLE READ und der Sperrung OPTIMISTIC initiiert wurden. Es ist eine Teilmenge von ATTEMPT_COUNT.
AVG_PARTICIPANTS	FLOAT64	Durchschnittliche Anzahl der Teilnehmer an jedem Commit-Versuch. Weitere Informationen zu Teilnehmern finden Sie unter Lebenszyklus 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. der Zeit vom Beginn des ersten Transaktionsvorgangs bis zum Commit oder Abbruch für alle Versuche einer Transaktion. Hinweis zur PostgreSQL-Schnittstelle: Datenbanken im PostgreSQL-Dialekt unterstützen diese Spalte nicht. Verwenden Sie stattdessen die Spalte TOTAL_LATENCY_DISTRIBUTION_JSON_STRING für Datenbanken im PostgreSQL-Dialekt. Wenn eine Transaktion mehrmals abgebrochen und dann erfolgreich festgeschrieben 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: ARRAY<STRUCT<   COUNT INT64,   MEAN FLOAT64,   SUM_OF_SQUARED_DEVIATION FLOAT64,   NUM_FINITE_BUCKETS INT64,   GROWTH_FACTOR FLOAT64,   SCALE FLOAT64,   BUCKET_COUNTS ARRAY<INT64>>> Weitere Informationen zu den Werten finden Sie unter Verteilung und Exponentiell. Verwenden Sie die Funktion SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64), um die Perzentillatenz aus der Verteilung zu berechnen. Sie gibt das geschätzte n-te Perzentil zurück. Ein ähnliches Beispiel finden Sie unter 99. Perzentil der Latenz für Transaktionen ermitteln. Weitere Informationen finden Sie unter Perzentile und Verteilungsmesswerte.
OPERATIONS_BY_TABLE	ARRAY<STRUCT>	Auswirkungen von INSERT- oder UPDATE-Vorgängen durch die Transaktion pro Tabelle. Dies wird durch die Anzahl der betroffenen Zeilen und die Anzahl der geschriebenen Byte angegeben. Hinweis zur PostgreSQL-Schnittstelle: Datenbanken im PostgreSQL-Dialekt unterstützen diese Spalte nicht. Verwenden Sie stattdessen die Spalte OPERATIONS_BY_TABLE_JSON_STRING für Datenbanken im PostgreSQL-Dialekt. Diese Spalte hilft bei der Visualisierung der Last auf Tabellen und bietet Einblicke in die Rate, mit der eine Transaktion in Tabellen schreibt. Geben Sie das Array so an: ARRAY<STRUCT<   TABLE STRING(MAX),   INSERT_OR_UPDATE_COUNT INT64,   INSERT_OR_UPDATE_BYTES INT64>>
TOTAL_LATENCY_DISTRIBUTION_JSON_STRING	STRING	Ein Histogramm der gesamten Commit-Latenz, d. h. der Zeit vom Beginn des ersten Transaktionsvorgangs bis zum Commit oder Abbruch für alle Versuche einer Transaktion. Eine JSON-kompatible Stringdarstellung der Statistik TOTAL_LATENCY_DISTRIBUTION. Der JSON-String ist ein JSON-Objekt mit derselben Struktur wie der in TOTAL_LATENCY_DISTRIBUTION definierte STRUCT. Wenn eine Transaktion mehrmals abgebrochen und dann erfolgreich festgeschrieben wird, wird die Latenz für jeden Versuch bis zum endgültigen erfolgreichen Commit gemessen. Die Werte werden in Sekunden gemessen. Diese Spalte wird in Datenbanken im GoogleSQL- und PostgreSQL-Dialekt unterstützt. Diese Spalte enthält die Verteilung. Verwenden Sie die Funktion SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64), um die Perzentillatenz aus der Verteilung zu berechnen. Sie gibt das geschätzte n-te Perzentil zurück. Ein ähnliches Beispiel finden Sie unter 99. Perzentil der Latenz für Transaktionen mit der Spalte TOTAL_LATENCY_DISTRIBUTION_JSON_STRING ermitteln. Weitere Informationen finden Sie unter Perzentile und Verteilungsmesswerte.
OPERATIONS_BY_TABLE_JSON_STRING	STRING	Auswirkungen von INSERT- oder UPDATE-Vorgängen durch die Transaktion pro Tabelle. Dies wird durch die Anzahl der betroffenen Zeilen und die Anzahl der geschriebenen Byte angegeben. Eine JSON-kompatible Stringdarstellung der Spalte OPERATIONS_BY_TABLE. Der JSON-String ist ein JSON-Objekt mit derselben Struktur wie der STRUCT, der in der Spalte OPERATIONS_BY_TABLE definiert ist. Diese Spalte wird in Datenbanken im GoogleSQL- und PostgreSQL-Dialekt unterstützt. Diese Spalte hilft, die Last auf Tabellen zu visualisieren, und bietet Einblicke in die Rate, mit der eine Transaktion in Tabellen schreibt.
COMMIT_LATENCY_DISTRIBUTION	ARRAY<STRUCT>	Ein Histogramm der Anzahl der Sekunden, die für die Ausführung des Commit-Vorgangs benötigt wurden. Hinweis zur PostgreSQL-Schnittstelle: Datenbanken im PostgreSQL-Dialekt unterstützen diese Spalte nicht. Verwenden Sie stattdessen die Spalte COMMIT_LATENCY_DISTRIBUTION_JSON_STRING für Datenbanken im PostgreSQL-Dialekt. Das Array hat die folgende Struktur: ARRAY<STRUCT<   COUNT INT64,   MEAN FLOAT64,   SUM_OF_SQUARED_DEVIATION FLOAT64,   NUM_FINITE_BUCKETS INT64,   GROWTH_FACTOR FLOAT64,   SCALE FLOAT64,   BUCKET_COUNTS ARRAY<INT64>>> Weitere Informationen zu den Werttypen finden Sie unter Verteilung und Exponentiell. Verwenden Sie die Funktion SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64), um die Perzentile der Commit-Latenz aus der Verteilung zu berechnen.
COMMIT_LATENCY_DISTRIBUTION_JSON_STRING	STRING	Eine JSON-kompatible Stringdarstellung der Statistik COMMIT_LATENCY_DISTRIBUTION. Der JSON-String ist ein JSON-Objekt mit derselben Struktur wie der STRUCT-Wert, der in der Spalte COMMIT_LATENCY_DISTRIBUTION definiert ist. Diese Spalte wird in Datenbanken im GoogleSQL- und PostgreSQL-Dialekt unterstützt. Verwenden Sie die Funktion SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64), um die Perzentile der Commit-Latenz aus der Verteilung zu berechnen.
PARTICIPANTS_DISTRIBUTION	ARRAY<STRUCT>	Ein Histogramm der Anzahl der Teilnehmer an jedem Commit-Versuch. Hinweis zur PostgreSQL-Schnittstelle: Datenbanken im PostgreSQL-Dialekt unterstützen diese Spalte nicht. Verwenden Sie stattdessen die Spalte PARTICIPANTS_DISTRIBUTION_JSON_STRING für Datenbanken im PostgreSQL-Dialekt. Das Array hat die folgende Struktur: ARRAY<STRUCT<   COUNT INT64,   MEAN FLOAT64,   SUM_OF_SQUARED_DEVIATION FLOAT64,   NUM_FINITE_BUCKETS INT64,   GROWTH_FACTOR FLOAT64,   SCALE FLOAT64,   BUCKET_COUNTS ARRAY<INT64>>> Weitere Informationen zu den Werttypen finden Sie unter Verteilung und Exponentiell. Verwenden Sie die Funktion SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64), um die Perzentile der Teilnehmer aus der Verteilung zu berechnen.
PARTICIPANTS_DISTRIBUTION_JSON_STRING	STRING	Eine JSON-kompatible Stringdarstellung der Statistik PARTICIPANTS_DISTRIBUTION. Der JSON-String ist ein JSON-Objekt mit derselben Struktur wie der STRUCT-Wert, der in der Spalte PARTICIPANTS_DISTRIBUTION definiert ist. Diese Spalte wird in Datenbanken im GoogleSQL- und PostgreSQL-Dialekt unterstützt. Verwenden Sie die Funktion SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64), um die Perzentile der Teilnehmer aus der Verteilung zu berechnen.

Beispielabfragen

Dieser Abschnitt enthält mehrere Beispiel-SQL-Anweisungen zum Abrufen von Transaktionsstatistiken. Sie können diese SQL-Anweisungen mit den Clientbibliotheken, der 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 von der höchsten zur 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;

Screenshot: 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 in der letzten Stunde erfassten Transaktionen 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;

Screenshot: 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 in einem bestimmten Zeitraum Statistiken erfasst hat:

• SPANNER_SYS.TXN_STATS_TOTAL_MINUTE: Zusammengefasste Statistiken für alle Transaktionen in 1-Minuten-Intervallen
• SPANNER_SYS.TXN_STATS_TOTAL_10MINUTE: Zusammengefasste Statistiken für alle Transaktionen in 10-Minuten-Intervallen
• SPANNER_SYS.TXN_STATS_TOTAL_HOUR: Zusammengefasste Statistiken für alle Transaktionen in einstündigen Intervallen

Zusammengefasste Statistiktabellen haben die folgenden Eigenschaften:

• Jede Tabelle enthält Daten für nicht überlappende Zeitintervalle der Länge, die im Tabellennamen angegeben ist.

• Die Intervalle beziehen sich auf die Uhrzeit. 1-Minuten-Intervalle enden nach einer vollen Minute, 10-Minuten-Intervalle enden alle 10 Minuten ab Beginn der vollen Stunde, 1-Stunden-Intervalle enden zu jeder 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 eine Zeile pro Zeitintervall.

• Die in den SPANNER_SYS.TXN_STATS_TOTAL_*-Tabellen erfassten Statistiken können Transaktionen enthalten, die Spanner nicht in den SPANNER_SYS.TXN_STATS_TOP_*-Tabellen erfasst hat.

• Einige Spalten in diesen Tabellen werden in Cloud Monitoring als Messwerte angezeigt. Die bereitgestellten Messwerte sind:

  • Anzahl der Commit-Versuche
  • Anzahl der Wiederholungsversuche für Commits
  • Transaktionsteilnehmer
  • Transaktionslatenzen
  • Geschriebene Bytes

  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 Versuche, die vor dem Aufruf von „commit“ abgebrochen werden. Diese Anzahl stellt die Gesamtzahl der Versuche während des angegebenen Intervalls dar. Weitere Informationen zu Intervallen finden Sie unter Intervalle.
COMMIT_ATTEMPT_COUNT	INT64	Gesamtzahl der Versuche, Transaktionen zu committen. Diese muss mit der Anzahl der Aufrufe der commit-Methode der Transaktion übereinstimmen. Diese Anzahl entspricht der Gesamtzahl der Commit-Versuche im angegebenen Intervall. Weitere Informationen zu Intervallen finden Sie unter Intervalle.
COMMIT_ABORT_COUNT	INT64	Gesamtzahl der Transaktionsversuche, die abgebrochen werden, einschließlich Versuche, die vor dem Aufruf der Methode commit der Transaktion abgebrochen werden. Diese Zahl entspricht der Gesamtzahl der Abbrüche im angegebenen Zeitraum. Weitere Informationen zu Intervallen finden Sie unter Intervalle.
COMMIT_RETRY_COUNT	INT64	Anzahl der Commit-Versuche, die Wiederholungsversuche aus zuvor abgebrochenen Versuchen sind. Eine Spanner-Transaktion wurde möglicherweise aufgrund von Sperrkonflikten oder vorübergehenden Ereignissen mehrmals versucht, bevor sie festgeschrieben wird. Eine hohe Anzahl von Wiederholungsversuchen im Verhältnis zu Commit-Versuchen deutet darauf hin, dass es Probleme gibt, die untersucht werden sollten. Weitere Informationen finden Sie unter Transaktionen und Commit-Zählungen auf dieser Seite.
COMMIT_FAILED_PRECONDITION_COUNT	INT64	Gesamtzahl der Versuche, Transaktionen zu committen, die Fehler aufgrund nicht erfüllter Vorbedingungen zurückgegeben haben, z. B. UNIQUE-Indexverletzungen, Zeile bereits vorhanden oder Zeile nicht gefunden.
SERIALIZABLE_PESSIMISTIC_TXN_COUNT	INT64	Gesamtzahl der Transaktionsversuche, die mit der Isolationsstufe SERIALIZABLE und der PESSIMISTIC-Sperre initiiert wurden. Es ist eine Teilmenge von ATTEMPT_COUNT.
REPEATABLE_READ_OPTIMISTIC_TXN_COUNT	INT64	Gesamtzahl der Transaktionsversuche, die mit der Isolationsstufe REPEATABLE READ und der OPTIMISTIC-Sperre initiiert wurden. Es ist eine Teilmenge von ATTEMPT_COUNT.
AVG_PARTICIPANTS	FLOAT64	Durchschnittliche Anzahl der Teilnehmer an jedem Commit-Versuch. Weitere Informationen zu Teilnehmern finden Sie unter Lebenszyklus 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. der Zeit vom Beginn des ersten Transaktionsvorgangs bis zum Commit oder Abbruch für alle Transaktionsversuche. Hinweis zur PostgreSQL-Schnittstelle: Datenbanken im PostgreSQL-Dialekt unterstützen diese Spalte nicht. Verwenden Sie stattdessen die Spalte TOTAL_LATENCY_DISTRIBUTION_JSON_STRING für Datenbanken im PostgreSQL-Dialekt. Wenn eine Transaktion mehrmals abgebrochen und dann erfolgreich festgeschrieben 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: ARRAY<STRUCT<   COUNT INT64,   MEAN FLOAT64,   SUM_OF_SQUARED_DEVIATION FLOAT64,   NUM_FINITE_BUCKETS INT64,   GROWTH_FACTOR FLOAT64,   SCALE FLOAT64,   BUCKET_COUNTS ARRAY<INT64>>> Weitere Informationen zu den Werten finden Sie unter Verteilung und Exponentiell. Verwenden Sie die Funktion SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64), um die Perzentillatenz aus der Verteilung zu berechnen. Sie gibt das geschätzte n-te Perzentil zurück. Ein Beispiel finden Sie unter 99. Perzentil der Latenz für Transaktionen ermitteln. Weitere Informationen finden Sie unter Perzentile und Verteilungsmesswerte.
OPERATIONS_BY_TABLE	ARRAY<STRUCT>	Auswirkungen von INSERT- oder UPDATE-Vorgängen durch alle Transaktionen pro Tabelle. Dies wird durch die Anzahl der betroffenen Zeilen und die Anzahl der geschriebenen Byte angegeben. Hinweis zur PostgreSQL-Schnittstelle: Datenbanken im PostgreSQL-Dialekt unterstützen diese Spalte nicht. Verwenden Sie stattdessen die Spalte OPERATIONS_BY_TABLE_JSON_STRING für Datenbanken im PostgreSQL-Dialekt. Diese Spalte hilft bei der Visualisierung der Last auf Tabellen und bietet Einblicke in die Rate, mit der die Transaktionen in Tabellen schreiben. Geben Sie das Array so an: ARRAY<STRUCT<   TABLE STRING(MAX),   INSERT_OR_UPDATE_COUNT INT64,   INSERT_OR_UPDATE_BYTES INT64>>
TOTAL_LATENCY_DISTRIBUTION_JSON_STRING	STRING	Ein Histogramm der gesamten Commit-Latenz, d. h. der Zeit vom Beginn des ersten Transaktionsvorgangs bis zum Commit oder Abbruch für alle Versuche einer Transaktion. Eine JSON-kompatible Stringdarstellung der Statistik TOTAL_LATENCY_DISTRIBUTION. Der JSON-String ist ein JSON-Objekt mit derselben Struktur wie der in TOTAL_LATENCY_DISTRIBUTION definierte STRUCT. Wenn eine Transaktion mehrmals abgebrochen und dann erfolgreich festgeschrieben wird, wird die Latenz für jeden Versuch bis zum endgültigen erfolgreichen Commit gemessen. Die Werte werden in Sekunden gemessen. Diese Spalte wird in Datenbanken im GoogleSQL- und PostgreSQL-Dialekt unterstützt. Diese Spalte enthält die Verteilung. Verwenden Sie die Funktion SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64), um die Perzentillatenz aus der Verteilung zu berechnen. Sie gibt das geschätzte n-te Perzentil zurück. Ein ähnliches Beispiel finden Sie unter 99. Perzentil der Latenz für Transaktionen mit der Spalte TOTAL_LATENCY_DISTRIBUTION_JSON_STRING ermitteln. Weitere Informationen finden Sie unter Perzentile und Verteilungsmesswerte.
OPERATIONS_BY_TABLE_JSON_STRING	STRING	Auswirkungen von INSERT- oder UPDATE-Vorgängen durch die Transaktion pro Tabelle. Dies wird durch die Anzahl der betroffenen Zeilen und die Anzahl der geschriebenen Byte angegeben. Eine JSON-kompatible Stringdarstellung der Spalte OPERATIONS_BY_TABLE. Der JSON-String ist ein JSON-Objekt mit derselben Struktur wie der STRUCT, der in der Spalte OPERATIONS_BY_TABLE definiert ist. Diese Spalte wird in Datenbanken im GoogleSQL- und PostgreSQL-Dialekt unterstützt. Diese Spalte hilft, die Last auf Tabellen zu visualisieren, und bietet Einblicke in die Rate, mit der eine Transaktion in Tabellen schreibt.
COMMIT_LATENCY_DISTRIBUTION	ARRAY<STRUCT>	Ein Histogramm der Anzahl der Sekunden, die für die Ausführung des Commit-Vorgangs benötigt wurden. Hinweis zur PostgreSQL-Schnittstelle: Datenbanken im PostgreSQL-Dialekt unterstützen diese Spalte nicht. Verwenden Sie stattdessen die Spalte COMMIT_LATENCY_DISTRIBUTION_JSON_STRING für Datenbanken im PostgreSQL-Dialekt. Das Array hat die folgende Struktur: ARRAY<STRUCT<   COUNT INT64,   MEAN FLOAT64,   SUM_OF_SQUARED_DEVIATION FLOAT64,   NUM_FINITE_BUCKETS INT64,   GROWTH_FACTOR FLOAT64,   SCALE FLOAT64,   BUCKET_COUNTS ARRAY<INT64>>> Weitere Informationen zu den Werttypen finden Sie unter Verteilung und Exponentiell. Verwenden Sie die Funktion SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64), um die Perzentile der Commit-Latenz aus der Verteilung zu berechnen.
COMMIT_LATENCY_DISTRIBUTION_JSON_STRING	STRING	Eine JSON-kompatible Stringdarstellung der Statistik COMMIT_LATENCY_DISTRIBUTION. Der JSON-String ist ein JSON-Objekt mit derselben Struktur wie der STRUCT-Wert, der in der Spalte COMMIT_LATENCY_DISTRIBUTION definiert ist. Diese Spalte wird in Datenbanken im GoogleSQL- und PostgreSQL-Dialekt unterstützt. Verwenden Sie die Funktion SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64), um die Perzentile der Commit-Latenz aus der Verteilung zu berechnen.
PARTICIPANTS_DISTRIBUTION	ARRAY<STRUCT>	Ein Histogramm der Anzahl der Teilnehmer an jedem Commit-Versuch. Hinweis zur PostgreSQL-Schnittstelle: Datenbanken im PostgreSQL-Dialekt unterstützen diese Spalte nicht. Verwenden Sie stattdessen die Spalte PARTICIPANTS_DISTRIBUTION_JSON_STRING für Datenbanken im PostgreSQL-Dialekt. Das Array hat die folgende Struktur: ARRAY<STRUCT<   COUNT INT64,   MEAN FLOAT64,   SUM_OF_SQUARED_DEVIATION FLOAT64,   NUM_FINITE_BUCKETS INT64,   GROWTH_FACTOR FLOAT64,   SCALE FLOAT64,   BUCKET_COUNTS ARRAY<INT64>>> Weitere Informationen zu den Werttypen finden Sie unter Verteilung und Exponentiell. Verwenden Sie die Funktion SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution, n FLOAT64), um die Perzentile der Teilnehmer aus der Verteilung zu berechnen.
PARTICIPANTS_DISTRIBUTION_JSON_STRING	STRING	Eine JSON-kompatible Stringdarstellung der Statistik PARTICIPANTS_DISTRIBUTION. Der JSON-String ist ein JSON-Objekt mit derselben Struktur wie der STRUCT-Wert, der in der Spalte PARTICIPANTS_DISTRIBUTION definiert ist. Diese Spalte wird in Datenbanken im GoogleSQL- und PostgreSQL-Dialekt unterstützt. Verwenden Sie die Funktion SPANNER_SYS.DISTRIBUTION_PERCENTILE(distribution_json_string, n FLOAT64), um die Perzentile der Teilnehmer aus der Verteilung zu berechnen.

Beispielabfragen

Dieser Abschnitt enthält mehrere Beispiel-SQL-Anweisungen zum Abrufen von Transaktionsstatistiken. Sie können diese SQL-Anweisungen mit den Clientbibliotheken, der gcloud spanner oder der Google Cloud Console ausführen.

Gesamtzahl der Commit-Versuche für alle Transaktionen 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.

99. Perzentil der Latenz für Transaktionen ermitteln

Die folgenden Abfragen geben das 99. Perzentil der Ausführungszeit für Abfragen zurück, die in den letzten 10 Minuten ausgeführt wurden.

Für Datenbanken im GoogleSQL-Dialekt können Sie die Spalte TOTAL_LATENCY_DISTRIBUTION verwenden:

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;

Verwenden Sie für Datenbanken im PostgreSQL-Dialekt stattdessen die Spalte TOTAL_LATENCY_JSON_DISTRIBUTION_JSON_STRING:

SELECT interval_end, avg_total_latency_seconds,
       SPANNER_SYS.DISTRIBUTION_PERCENTILE(total_latency_distribution_json_string, 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 Latenz und der Latenz im 99. Perzentil. Die Latenz für das 99. Perzentil hilft, mögliche Ausreißertransaktionen mit hoher Latenz zu identifizieren.

Das Ergebnis enthält nur eine Zeile, da aggregierte Statistiken für jede Zeitdauer nur einen Eintrag pro interval_end enthalten.

Datenaufbewahrung

Spanner bewahrt Daten für jede Tabelle mindestens für die folgenden Zeiträume auf:

• SPANNER_SYS.TXN_STATS_TOP_MINUTE und SPANNER_SYS.TXN_STATS_TOTAL_MINUTE: Intervalle, die die letzten 6 Stunden abdecken.

• SPANNER_SYS.TXN_STATS_TOP_10MINUTE und SPANNER_SYS.TXN_STATS_TOTAL_10MINUTE: Intervalle der letzten 4 Tage.

• SPANNER_SYS.TXN_STATS_TOP_HOUR und SPANNER_SYS.TXN_STATS_TOTAL_HOUR: Intervalle, die die letzten 30 Tage abdecken.

Hinweis: Sie können nicht verhindern, dass Spanner Transaktionsstatistiken erfasst. Wenn Sie die Daten in diesen Tabellen löschen möchten, müssen Sie die mit den Tabellen verknüpfte Datenbank löschen oder warten, bis Spanner die Daten automatisch entfernt. Sie können die Aufbewahrungsdauer für diese Tabellen nicht verlängern.

Transaktionsstatistiken in Spanner geben Einblicke darüber, wie eine Anwendung die Datenbank verwendet, und sind nützlich, wenn Sie Leistungsprobleme untersuchen. Sie können beispielsweise prüfen, ob es langsam ausgeführte Transaktionen gibt, die zu Konflikten führen könnten, oder potenzielle Quellen für eine hohe Last identifizieren, z. B. große Mengen an Aktualisierungen für eine bestimmte Spalte.

Transaktionen und Commit-Anzahl verstehen

Eine Spanner-Transaktion muss möglicherweise mehrmals versucht werden, bevor sie festgeschrieben wird. Dies tritt am häufigsten auf, wenn zwei Transaktionen gleichzeitig versuchen, dieselben Daten zu bearbeiten, und eine der Transaktionen abgebrochen werden muss, um die Isolationseigenschaft der Transaktion beizubehalten. Andere vorübergehende Ereignisse, die ebenfalls zum Abbruch einer Transaktion führen können:

• Vorübergehende Netzwerkprobleme.

• Änderungen am Datenbankschema werden angewendet, während ein Transaktions-Commit ausgeführt wird.

• Die Cloud 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 Wiederholungsmechanismus implementiert. Wenn Sie eine benutzerdefinierte Version des Clientcodes verwenden, binden Sie Ihre Transaktions-Commits in eine Wiederholungsschleife ein.

Eine Spanner-Transaktion kann auch aufgrund eines nicht wiederholbaren Fehlers abgebrochen werden, z. B. aufgrund einer Transaktionszeitüberschreitung, eines Berechtigungsproblems oder eines ungültigen Tabellen- oder Spaltennamens. Solche Transaktionen müssen nicht wiederholt werden und die Spanner-Clientbibliothek gibt den Fehler sofort zurück.

In der folgenden Tabelle finden Sie einige Beispiele dafür, wie COMMIT_ATTEMPT_COUNT, COMMIT_ABORT_COUNT und COMMIT_RETRY_COUNT in verschiedenen Szenarien protokolliert 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 Transaktionsstatistiken sind aggregierte Daten für ein Zeitintervall. In einem bestimmten Intervall kann es vorkommen, dass ein Transaktionsabbruch und ein Wiederholungsversuch an den Grenzen auftreten und in verschiedene Buckets fallen. Daher stimmen Abbrüche und Wiederholungsversuche in einem bestimmten Zeitintervall möglicherweise nicht überein.

Diese Statistiken sind für die Fehlerbehebung und Introspektion gedacht und sind nicht garantiert zu 100% genau. Statistiken werden im Arbeitsspeicher zusammengefasst, 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

Sie können SQL-Code oder das Dashboard Transaktionsstatistiken verwenden, um die Transaktionen in Ihrer Datenbank aufzurufen, die aufgrund von Sperrkonflikten hohe Latenzen verursachen könnten.

In den folgenden Abschnitten wird beschrieben, wie Sie solche Transaktionen mithilfe von SQL-Code untersuchen können.

Zeitraum für die Untersuchung auswählen

Diese finden Sie in der Anwendung, die Spanner verwendet.

Nehmen Sie für diese Übung an, dass das Problem am 17. Mai 2020 gegen 17:20 Uhr aufgetreten ist.

Mit Transaktions-Tags können Sie die Quelle der Transaktion identifizieren und die Tabelle mit den Transaktionsstatistiken und die Tabelle mit den Sperrstatistiken korrelieren, um Probleme mit Sperrkonflikten effektiv zu beheben. Weitere Informationen finden Sie unter Fehlerbehebung mit Transaktions-Tags.

Transaktionsstatistiken für den ausgewählten Zeitraum erfassen

Fragen Sie zum Starten der Prüfung 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 geä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;

In der folgenden Tabelle sind Beispieldaten aufgeführt, die von der Abfrage zurückgegeben werden.

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

Die aggregierte Latenz und die Anzahl der Abbrüche sind in den hervorgehobenen Zeiträumen höher. Wählen Sie ein beliebiges 10-Minuten-Intervall aus, in dem die aggregierte Latenz und die Anzahl der Abbrüche oder beides hoch sind. Das Intervall, das bei 2020-05-17T18:40:00 endet, wird im nächsten Schritt verwendet, um zu ermitteln, welche Transaktionen zu einer hohen Latenz und einer hohen Anzahl von abgebrochenen Transaktionen beitragen.

Transaktionen mit hoher Latenz identifizieren

Fragen Sie die Tabelle TXN_STATS_TOP_10MINUTE für das Intervall ab, das im vorherigen Schritt ausgewählt wurde. Anhand dieser Daten können Sie ermitteln, welche Transaktionen eine hohe Latenz oder eine hohe Anzahl von Abbrüchen oder beides aufweisen.

Führen Sie die folgende Abfrage aus, um die Transaktionen mit den größten Auswirkungen auf die Leistung in absteigender Reihenfolge der Gesamtlatenz für das Beispielintervall abzurufen, das am 2020-05-17T18:40:00 endet.

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

Die erste Zeile (hervorgehoben) in der vorherigen Tabelle zeigt eine Transaktion mit hoher Latenz aufgrund einer hohen Anzahl von Commit-Abbrüchen. Es gibt auch eine hohe Anzahl von Commit-Wiederholungen, was darauf hindeutet, dass die abgebrochenen Commits anschließend wiederholt wurden. Im nächsten Schritt wird genauer untersucht, was dieses Problem verursacht.

Spalten identifizieren, die an einer Transaktion mit hoher Latenz beteiligt sind

In diesem Schritt prüfen Sie, ob Transaktionen mit hoher Latenz für dieselben Spalten ausgeführt werden. Dazu rufen Sie read_columns-, write_constructive_columns- und write_delete_tables-Daten für Transaktionen mit einer hohen Anzahl von Abbrüchen ab. 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. Es gibt auch einige Schreibkonflikte, da die Transaktionen in dieselbe Spalte schreiben, d. h. TestHigherLatency._exists.

Ermitteln, wie sich die Transaktionsleistung im Laufe der Zeit verändert hat

Sie 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 dieser Ausgabe ist die Gesamtlatenz für den hervorgehobenen Zeitraum hoch. 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 war die hohe Anzahl von Commit-Abbrüchen die Ursache für die hohe Latenz. Im nächsten Schritt sehen Sie sich die Fehlermeldungen zum Abbruch des Commits an, die von der Anwendung empfangen wurden, um den Grund für die Abbrüche zu erfahren. Wenn Sie die Logs in der Anwendung prüfen, können Sie sehen, dass die Anwendung ihre Arbeitslast in dieser Zeit tatsächlich geändert hat. Das bedeutet, dass eine andere Transaktionsform mit einem hohen attempts_per_second-Wert aufgetreten ist und dass diese andere Transaktion (vielleicht ein nächtlicher Bereinigungsjob) für die zusätzlichen Sperrkonflikte verantwortlich war.

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

Die Transaktion mit dem fprint 1557557373282541312 wurde 44.232 Mal abgebrochen, aber nie wiederholt. Das sieht verdächtig aus, da die Anzahl der Abbrüche hoch ist und es unwahrscheinlich ist, dass jeder Abbruch durch einen nicht wiederholbaren Fehler verursacht wurde. Die Transaktion mit dem fprint 5776062322886969344 ist dagegen weniger verdächtig, da die Gesamtzahl der Abbrüche nicht so hoch ist.

Die folgende Abfrage gibt weitere Details zur Transaktion mit dem fprint 1557557373282541312 zurück,einschließlich read_columns, write_constructive_columns und write_delete_tables. Anhand dieser Informationen können Sie die Transaktion im Clientcode identifizieren, wo die Wiederholungslogik für dieses Szenario überprü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

Die Transaktion umfasst einen Lesevorgang in der ausgeblendeten Spalte Singers._exists, um zu prüfen, ob eine Zeile vorhanden ist. 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 die Wiederholung von Transaktionen wie erwartet funktioniert.

Nächste Schritte

• Weitere Informationen zu Tools zur Selbstbeobachtung
• Mehr über die weiteren Informationen erfahren, die Spanner für jede Datenbank in den Informationsschematabellen der Datenbank speichert
• SQL-Best-Practices für Spanner
• Hohe CPU-Auslastung untersuchen