Transaktionsstatistiken

Cloud Spanner bietet eingebundene Tabellen, die Statistiken zu Transaktionen speichern. 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 wie executeQuery und gcloud spanner databases execute-sql verfügbar. Andere Cloud Spanner-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.

  • 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 für SQL-Abfragen um 11:59:30 Uhr die folgenden neuesten Intervalle verfügbar:

    • 1 Minute: 11:58:01–11:59:00 Uhr
    • 10 Minuten: 11:40:01–11:50:00 Uhr
    • 1 Stunde: 10:00:01–11:00:00 Uhr
  • Cloud Spanner gruppiert die Statistiken nach FPRINT (Fingerabdruck) der Transaktionen. FPRINT ist der Hash, der basierend auf den an der Transaktion teilnehmenden Vorgängen 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 Cloud Spanner während des angegebenen Intervalls Statistiken erfasst.

Wenn Cloud 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 Commit-Versuchen und den im angegebenen Intervall geschriebenen Byte.

Tabellenschema

Spaltenname Typ Beschreibung
INTERVAL_END TIMESTAMP Ende des Zeitintervalls, in dem die einbezogenen Transaktionen ausgeführt wurden.
FPRINT INT64 Der Fingerabdruck ist der Hash, der basierend auf den an der Transaktion teilnehmenden Vorgängen berechnet wird. 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.
WRITE_DELETE_TABLES ARRAY<STRING> Der Satz von Tabellen, in denen Zeilen gelöscht oder durch die Transaktion ersetzt wurden.
COMMIT_ATTEMPT_COUNT INT64 Gesamtzahl der Commit-Versuche für die Transaktion.
COMMIT_FAILED_PRECONDITION_COUNT INT64 Gesamtzahl der Vorbedingungsfehler (FAILED_PRECONDITION) für die Transaktion.
COMMIT_ABORT_COUNT INT64 Anzahl, wie oft die Commits für die Transaktion abgebrochen wurden.
AVG_PARTICIPANTS FLOAT64 Durchschnittliche Anzahl der Teilnehmer an jedem Commit-Versuch. Weitere Informationen zu Teilnehmern finden Sie unter Lebensdauer von Lese- und Schreibvorgängen in Cloud Spanner.
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.

Beispielabfragen

Dieser Abschnitt enthält mehrere Beispiel-SQL-Anweisungen zum Abrufen von Transaktionsstatistiken. Sie können diese SQL-Anweisungen mit den Clientbibliotheken, mit dem gcloud-Befehlszeilentool oder mit der 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,
       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 avg_bytes
40015598317 [] ["Routes"] ["Users"] 0.006578737 0.006547737 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"] ["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 von aggregierten Daten für alle Transaktionen, für die Cloud Spanner in einem bestimmten Zeitraum Statistiken erfasst hat:

  • SPANNER_SYS.TXN_STATS_TOTAL_MINUTE: Zusammengefasste Statistiken für alle Transaktionen in Intervallen von einer Minute
  • SPANNER_SYS.TXN_STATS_TOTAL_10MINUTE: Zusammengefasste Statistiken für alle Transaktionen in Intervallen von 10 Minuten
  • SPANNER_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 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:01–11:59:00 Uhr
    • 10 Minuten: 11:40:01–11:50:00 Uhr
    • 1 Stunde: 10:00:01–11:00:00 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 von Cloud Spanner nicht in den SPANNER_SYS.TXN_STATS_TOP_*-Tabellen erfasst wurden.

Tabellenschema

Spaltenname Typ Beschreibung
INTERVAL_END TIMESTAMP Ende des Zeitintervalls, in dem diese Statistik erfasst wurde.
COMMIT_ATTEMPT_COUNT INT64 Gesamtzahl der Commit-Versuche für die Transaktion.
COMMIT_FAILED_PRECONDITION_COUNT INT64 Gesamtzahl der Vorbedingungsfehler (FAILED_PRECONDITION) für die Transaktion.
COMMIT_ABORT_COUNT INT64 Anzahl, wie oft die Commits für die Transaktion abgebrochen wurden.
AVG_PARTICIPANTS FLOAT64 Durchschnittliche Anzahl der Teilnehmer an jedem Commit-Versuch. Weitere Informationen zu Teilnehmern finden Sie unter Lebensdauer von Lese- und Schreibvorgängen in Cloud Spanner.
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.

Beispielabfragen

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

Gesamtzahl der Commit-Versuche für eine Transaktion in einem bestimmten Zeitraum 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.

Datenaufbewahrung

Cloud Spanner speichert die Daten für jede Tabelle mindestens für die folgenden Zeiträume:

  • SPANNER_SYS.TXN_STATS_TOP_MINUTE und SPANNER_SYS.TXN_STATS_TOTAL_MINUTE: Intervalle der letzten 6 Stunden.

  • 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 der letzten 30 Tage.

Transaktionsstatistiken in Cloud Spanner bieten einen Einblick in die Verwendung der Datenbank durch eine Anwendung und 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.

Fehlerbehebung bei Datenbankinhalten mithilfe von Transaktionsstatistiken

Schritt 1: Zeitraum für die Untersuchung auswählen

Diese finden Sie in der Anwendung, die Cloud Spanner verwendet.

Beispiel: Das Problem tritt am 17. Mai 2020 gegen 17:20 Uhr auf.

Schritt 2: 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.

Schritt 3: 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
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
2020-05-17 18:40:00-07:00 15185072816865185658 0.3508 0.0139 278802 142205
2020-05-17 18:40:00-07:00 15435530087434255496 0.1633 0.0142 129012 27177
2020-05-17 18:40:00-07:00 14175643543447671202 0.1423 0.0133 5357 636
2020-05-17 18:40:00-07:00 898069986622520747 0.0198 0.0158 6 0
2020-05-17 18:40:00-07:00 10510121182038036893 0.0168 0.0125 7 0
2020-05-17 18:40:00-07:00 9287748709638024175 0.0159 0.0118 4269 1
2020-05-17 18:40:00-07:00 7129109266372596045 0.0142 0.0102 182227 0
2020-05-17 18:40:00-07:00 15630228555662391800 0.0120 0.0107 58 0
2020-05-17 18:40:00-07:00 7907238229716746451 0.0108 0.0097 65 0
2020-05-17 18:40:00-07:00 10158167220149989178 0.0095 0.0047 3454 0
2020-05-17 18:40:00-07:00 9353100217060788102 0.0093 0.0045 725 0
2020-05-17 18:40:00-07:00 9521689070912159706 0.0093 0.0045 164 0
2020-05-17 18:40:00-07:00 11079878968512225881 0.0064 0.0019 65 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. Im nächsten Schritt untersuchen wir das Problem, um die Ursache zu ermitteln.

Schritt 4: Ermitteln, welche Spalten an einer Transaktion mit hoher Latenz beteiligt sind

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
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.

Schritt 5: 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_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_failed_precondition_count avg_bytes
2020-05-17 16:40:00-07:00 0.095 0.010 53230 4752 0 91
2020-05-17 16:50:00-07:00 0.069 0.009 61264 3589 0 91
2020-05-17 17:00:00-07:00 0.150 0.010 75868 10557 0 91
2020-05-17 17:10:00-07:00 0.248 0.013 103151 30220 0 91
2020-05-17 17:20:00-07:00 0.310 0.012 130078 45655 0 91
2020-05-17 17:30:00-07:00 0.294 0.012 160064 64930 0 91
2020-05-17 17:40:00-07:00 0.315 0.013 209614 104949 0 91
2020-05-17 17:50:00-07:00 0.322 0.012 215682 100408 0 90
2020-05-17 18:00:00-07:00 0.310 0.012 230932 106728 0 91
2020-05-17 18:10:00-07:00 0.309 0.012 259645 131049 0 91
2020-05-17 18:20:00-07:00 0.315 0.013 272171 137910 0 90
2020-05-17 18:30:00-07:00 0.292 0.013 258944 121475 0 91
2020-05-17 18:40:00-07:00 0.350 0.013 278802 142205 0 91
2020-05-17 18:50:00-07:00 0.302 0.013 256259 115626 0 91
2020-05-17 19:00:00-07:00 0.315 0.014 250560 110662 0 91
2020-05-17 19:10:00-07:00 0.271 0.014 238384 99025 0 91
2020-05-17 19:20:00-07:00 0.273 0.014 219687 84019 0 91
2020-05-17 19:30:00-07:00 0,198 0.013 195357 59370 0 91
2020-05-17 19:40:00-07:00 0.181 0.013 167514 35705 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 als auch commit_abort_coun 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.

6. Schritt: Schlussfolgerung

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.

Nächste Schritte