Fehlerbehebung bei Zeitüberschreitungen für Cloud Spanner

Auf dieser Seite erhalten Sie einen Überblick über die überschrittenen Cloud Spanner-Zeitüberschreitungen: was sie sind, warum sie auftreten und wie Sie sie beheben und beheben können.

Beim Zugriff auf Spanner APIs können Anfragen aufgrund von DEADLINE_EXCEEDED-Fehlern fehlschlagen. Dieser Fehler weist darauf hin, dass innerhalb des konfigurierten Zeitlimits keine Antwort empfangen wurde.

Eine Fristüberschreitung kann aus vielen verschiedenen Gründen auftreten, darunter überlastete Spanner-Instanzen, nicht optimierte Schemas oder nicht optimierte Abfragen. Auf dieser Seite werden häufige Szenarien beschrieben, in denen eine Frist überschritten wurde, für die ein Fehler aufgetreten ist. Außerdem findest du dort einen Leitfaden zur Untersuchung und Behebung dieser Probleme.

Cloud Spanner-Philosophie und Philosophie für Wiederholung

Die Frist und die Philosophie für Spanner ist anders als bei vielen anderen Systemen. In Spanner sollten Sie eine Zeitüberschreitungsfrist als maximale Zeitspanne festlegen, in der eine Antwort nützlich ist. Es wird nicht empfohlen, eine künstliche Frist festzulegen, um denselben Vorgang sofort noch einmal auszuführen. Das kann dazu führen, dass Vorgänge nie abgeschlossen werden. In diesem Zusammenhang werden die folgenden Strategien und Vorgänge nicht empfohlen, da sie kontraproduktiv sind und das interne Wiederholungsverhalten von Spanner umgehen:

  • Die Frist ist zu kurz. Das bedeutet, dass der Vorgang nicht widerstandsfähig ist und die Latenzzeit nur gelegentlich erhöht wird und dass der Vorgang vor einer Zeitüberschreitung nicht abgeschlossen werden kann. Legen Sie stattdessen eine Frist fest, die angibt, wie lange eine Antwort maximal nützlich ist.

  • Legen Sie eine Frist fest, die zu lang ist, und brechen Sie den Vorgang ab, bevor die Frist überschritten ist. Dies führt zu Wiederholungen und verschwendeter Arbeit bei jedem Versuch. Insgesamt kann dies zu einer erheblichen zusätzlichen Belastung Ihrer Instanz führen.

Was ist eine Frist, die überschritten wurde?

Wenn Sie eine der Spanner-Clientbibliotheken verwenden, übernimmt die zugrunde liegende gRPC-Ebene die Kommunikation, das Marshaling, Unmarshalling und die Erzwingung von Fristen. Mit Fristen kann Ihre Anwendung angeben, wie lange auf den Abschluss einer Anfrage gewartet werden soll, bevor die Anfrage beendet wird. Dabei wird die Fehlerfrist überschritten.

Im Leitfaden zur Zeitüberschreitung sehen Sie, wie Sie in den unterstützten Spanner-Clientbibliotheken Fristen (oder Zeitüberschreitungen) festlegen können. Die Spanner-Clientbibliotheken verwenden Standardzeitlimits und Richtlinieneinstellungen für Wiederholungsversuche, die in den folgenden Konfigurationsdateien definiert sind:

Weitere Informationen zu gRPC-Fristen finden Sie unter gRPC und Fristen.

Häufige Fehler bei Fristüberschreitungen untersuchen und beheben

Probleme mit der Data Access API

Damit die Probleme beim Datenzugriff nicht auftreten, muss eine Spanner-Instanz für Ihre spezifischen Arbeitslasten entsprechend konfiguriert werden. In den folgenden Abschnitten wird beschrieben, wie Sie verschiedene Probleme mit der Data Access API untersuchen und beheben.

CPU-Auslastung der Spanner-Instanz prüfen

Die Anfragelatenz kann deutlich zunehmen, da die CPU-Auslastung den empfohlenen Fehlergrenzwert überschreitet. Sie können die CPU-Auslastung von Spanner in der Monitoring-Konsole in der Google Cloud Console prüfen. Sie können auch Benachrichtigungen auf Grundlage der CPU-Auslastung der Instanz erstellen.

Lösung

Eine Anleitung zum Reduzieren der CPU-Auslastung der Instanz finden Sie unter CPU-Auslastung reduzieren.

Aufschlüsselung der End-to-End-Latenz der Anfrage prüfen

Wenn eine Anfrage vom Client an die Spanner-Server und zurück übertragen wird, müssen verschiedene Netzwerk-Hops gestellt werden: von der Clientbibliothek an das Google Front-End (GFE), vom GFE zur Spanner Spanner API-Front-End und schließlich vom Spanner API-Front-End zur Spanner-Datenbank. Wenn es in einer dieser Phasen Netzwerkprobleme gibt, werden möglicherweise Fehler bei der Frist überschritten.

Es ist möglich, die Latenz in jeder Phase zu erfassen. Weitere Informationen finden Sie im Leitfaden für die Latenz. Weitere Informationen zur Diagnoseanleitung finden Sie im Hilfeartikel Latenzprobleme diagnostizieren.

Lösung

Sobald Sie die Latenzaufschlüsselung abgerufen und das Problem mit der Latenz diagnostiziert haben, können Sie mithilfe des Leitfadens zur Fehlerbehebung bei Latenzproblemen die Ursache der Latenz ermitteln und nachvollziehen, warum dies der Fall ist.

Probleme mit der Data API

Bestimmte nicht optimale Nutzungsmuster der Data API können zu einer Frist für überschrittene Fehler führen. In diesem Abschnitt finden Sie Richtlinien zur Prüfung dieser nicht optimalen Nutzungsmuster.

Auf teure Abfragen prüfen

Wenn Sie versuchen, teure Abfragen auszuführen, die nicht innerhalb der konfigurierten Zeitüberschreitung in den Clientbibliotheken ausgeführt werden, kann das zu einer Fristüberschreitung führen. Einige teure Abfragen sind beispielsweise vollständige Scans einer großen Tabelle, Querschnitte über mehrere große Tabellen oder eine Abfrageausführung mit einem Prädikat auf Basis einer Nicht-Schlüsselspalte (auch eines vollständigen Tabellenscans).

Sie können teure Abfragen mit der Tabelle für Abfragestatistiken und der Tabelle mit den Transaktionsstatistiken prüfen. Diese Tabellen enthalten Informationen zu langsamen Abfragen und Transaktionen, z. B. die durchschnittliche Anzahl der gelesenen Zeilen, die durchschnittliche Anzahl der gelesenen Byte und die durchschnittliche Anzahl der gescannten Zeilen. Außerdem können Sie Abfrageausführungspläne generieren, um die Ausführung Ihrer Abfragen weiter zu prüfen.

Lösung

Weitere Informationen zur Optimierung Ihrer Abfragen finden Sie im Leitfaden Best Practices für SQL-Abfragen. Sie können auch die Daten verwenden, die über die oben genannten Statistiktabellen und Ausführungspläne abgerufen wurden, um Ihre Abfragen zu optimieren und Schemaänderungen an Ihren Datenbanken vorzunehmen. Diese Best Practices können dazu beitragen, die Ausführungszeit der Anweisungen zu verringern.

Auf Sperrkonflikte prüfen

Spanner-Transaktionen müssen Sperren für Commit erhalten. Anwendungen, die mit einem hohen Durchsatz ausgeführt werden, können dazu führen, dass Transaktionen um dieselben Ressourcen konkurrieren. Dadurch kommt es zu einer längeren Wartezeit bei Sperren und zu einer Beeinträchtigung der Gesamtleistung. Das kann dazu führen, dass Fristen für Lese- oder Schreibanfragen überschritten werden.

Die Ursache von Lese-/Schreibtransaktionen mit hoher Latenz können Sie in der Tabelle „Sperrstatistiken“ und im folgenden Blogpost ermitteln. In der Tabelle mit den Sperrstatistiken finden Sie die Zeilenschlüssel mit den höchsten Wartezeiten.

In diesem Leitfaden zur Fehlerbehebung bei Sperrkonflikten wird erläutert, wie Sie die Transaktionen finden, die auf die im Sperrkonflikt betroffenen Spalten zugreifen. Mithilfe des Leitfadens zur Fehlerbehebung mit Transaktions-Tags können Sie außerdem herausfinden, welche Transaktionen an einem Sperrkonflikt beteiligt sind.

Lösung

Wende diese Best Practices an, um Sperren zu verringern. Verwenden Sie außerdem schreibgeschützte Transaktionen für einfache Leseanwendungsfälle, um Sperrkonflikte mit den Schreibvorgängen zu vermeiden. Die Verwendung von Lese-/Schreibtransaktionen sollte für Schreib- oder gemischte Lese-/Schreib-Workflows reserviert sein. Das Ausführen dieser Schritte sollte die Gesamtlatenz der Transaktionsausführungszeit verbessern und die Frist für das Überschreiten von Fehlern reduzieren.

Nach nicht optimierten Schemas suchen

Bevor Sie ein optimales Datenbankschema für Ihre Spanner-Datenbank erstellen, sollten Sie sich überlegen, welche Arten von Abfragen in Ihrer Datenbank ausgeführt werden. Suboptimale Schemas können zu Leistungsproblemen führen, wenn einige Abfragen ausgeführt werden. Diese Leistungsprobleme können verhindern, dass Anfragen innerhalb der konfigurierten Frist abgeschlossen werden.

Lösung

Das optimale Schemadesign hängt von den Lese- und Schreibvorgängen in Ihrer Datenbank ab. Die Best Practices für das Schemadesign und die Best Practices für SQL-Dialekte sollten unabhängig von den Schemaspezifikationen beachtet werden. Durch Ausführen dieser Richtlinien kannst du die häufigsten Schemadesign-Probleme vermeiden. Einige andere Ursachen für eine schlechte Leistung werden Ihrer Auswahl der Primärschlüssel, dem Tabellenlayout (siehe Verschränkte Tabellen für schnelleren Zugriff), dem Schemadesign (siehe Optimierung des Schemas für die Leistung) und der Leistung des Knotens zugeordnet, der in Ihrer Spanner-Instanz konfiguriert ist (siehe regionale Limits oder multiregionale Limits).

Auf Hotspots prüfen

Da Spanner eine verteilte Datenbank ist, muss das Schemadesign die Hotspots verhindern. Durch das Erstellen monoton steigender Spalten wird beispielsweise die Anzahl der Splits begrenzt, mit denen Spanner die Arbeitslast gleichmäßig verteilen kann. Diese Engpässe können zu Zeitüberschreitungen führen. Außerdem können Sie mit Key Visualizer Leistungsprobleme aufgrund von Hotspots beheben.

Lösung

Lesen Sie als ersten Schritt die in dem vorherigen Abschnitt Nach nicht optimierten Schemas prüfen genannten Lösungen. Überarbeiten Sie Ihr Datenbankschema neu und verwenden Sie verschränkte Indexe, um Indexe zu vermeiden, die zu Hotspots führen können. Wenn Sie das Problem so nicht beheben können, lesen Sie den Artikel Primärschlüssel auswählen, um Hotspots zu verhindern. Vermeiden Sie schließlich suboptimale Trafficmuster wie Lesevorgänge im großen Bereich, die die Aufteilung auf Last verhindern könnten.

Auf falsch konfigurierte Zeitüberschreitungen prüfen

Die Clientbibliotheken bieten angemessenen Zeitlimits für alle Anfragen in Spanner. Diese Standardkonfigurationen müssen möglicherweise jedoch an Ihre spezifische Arbeitslast angepasst werden. Es lohnt sich, die Kosten Ihrer Abfragen zu beobachten und die Fristen anzupassen, die für Ihren speziellen Anwendungsfall geeignet sind.

Lösung

Die Standardeinstellungen für Zeitüberschreitungen sind für die meisten Anwendungsfälle geeignet. Nutzer können diese Konfigurationen überschreiben (siehe Benutzerdefiniertes Zeitlimit und Wiederholungsanleitung). Es wird jedoch nicht empfohlen, aggressivere Zeitüberschreitungen zu verwenden als die Standardeinstellungen. Wenn Sie das Zeitlimit ändern möchten, legen Sie es auf die tatsächliche Zeit fest, in der die Anwendung auf das Ergebnis warten soll. Sie können mit längeren konfigurierten Zeitlimits experimentieren. Sie sollten jedoch nie ein Zeitlimit festlegen, das kürzer als die tatsächliche Wartezeit der Anwendung ist, da dies dazu führen würde, dass der Vorgang häufiger wiederholt wird.

Probleme mit der Admin API

Admin API-Anfragen sind im Vergleich zu Data API-Anfragen teuer. Administratoranfragen wie CreateInstance, CreateDatabase oder CreateBackups können viele Sekunden dauern, bevor du eine Antwort erhältst. Spanner-Clientbibliotheken legen feste Fristen von 60 Minuten für Anfragen von Instanzen und Datenbanken fest. So wird sichergestellt, dass der Server die Anfrage durchführen kann, bevor der Client ein neuer Versuch startet oder fehlschlägt.

Lösung

Wenn Sie die Google Spanner-Clientbibliothek verwenden, müssen Sie darauf achten, dass die Clientbibliothek aktualisiert und auf die neueste Version aktualisiert ist. Wenn Sie direkt über eine von Ihnen erstellte Clientbibliothek auf die Spanner API zugreifen, sollten Sie darauf achten, dass Sie keine aggressiveren Zeitlimits als die Standardeinstellungen (60 Minuten) für Ihre Instanzanfragen und Datenbankanfragen haben.

Probleme mit der Google Cloud Console

Abfragen, die von der Abfrageseite der Google Cloud Console aus gestellt wurden, dürfen nicht länger als fünf Minuten sein. Wenn Sie eine teure Abfrage erstellen, deren Ausführung mehr als fünf Minuten dauert, wird die folgende Fehlermeldung angezeigt:

Screenshot der Cloud Console-Zeitüberschreitung überschritten

Das Back-End bricht die fehlgeschlagene Abfrage ab und die Transaktion wird bei Bedarf zurückgesetzt.

Lösung

Sie können die Abfrage mit dem Best Practices für SQL-Abfragen umschreiben.

Probleme mit Dataflow

In Apache Beam beträgt die Standardzeitüberschreitungskonfiguration zwei Stunden für Lesevorgänge und 15 Sekunden für Commit-Vorgänge. Diese Konfigurationen ermöglichen einen längeren Betrieb im Vergleich zu den Zeitlimits für die eigenständige Clientbibliothek. Es ist jedoch möglich, dass eine Zeitüberschreitung und eine Zeitüberschreitung überschritten werden, wenn die Aufgaben zu groß sind. Derzeit kann die Apache Beam-Commit-Zeitkonfiguration nur bei Bedarf angepasst werden.

Lösung

Wenn bei den Schritten zu ReadFromSpanner / Execute query / Read from Cloud Spanner / Read from Partitions eine Zeitüberschreitung aufgetreten ist, können Sie in der Tabelle mit der Abfragestatistik nachsehen, welche Abfrage eine große Anzahl von Zeilen gescannt hat. Ändern Sie dann diese Abfragen, um die Ausführungszeit zu reduzieren.

In der folgenden Ausnahmenachricht wird ein weiteres Beispiel für eine Fehlermeldung angezeigt, die überschritten wurde:

exception:
     org.apache.beam.sdk.util.UserCodeException:
     com.google.cloud.spanner.SpannerException: DEADLINE_EXCEEDED:
     io.grpc.StatusRuntimeException: DEADLINE_EXCEEDED: deadline exceeded after
     3599.999905380s.
     [remote_addr=batch-spanner.googleapis.com/172.217.5.234:443] at
 org.apache.beam.runners.dataflow.worker.GroupAlsoByWindowsParDoFn$1.output(GroupAlsoByWindowsParDoFn.java:184)

Das Zeitlimit wurde überschritten, weil die Arbeitselemente zu groß sind. In diesem Fall können die folgenden beiden Empfehlungen Abhilfe schaffen. Erstens kannst du versuchen, den Shuffle-Dienst zu aktivieren, wenn er noch nicht aktiviert ist. Zweitens kannst du die Konfigurationen in deiner Datenbank anpassen, z. B. maxPartitions und partitionSizeBytes. Weitere Informationen finden Sie unter PartitionOptions. Hier finden Sie Informationen dazu, wie Sie versuchen, die Größe der Aufgabe zu verringern. Ein Beispiel dafür finden Sie in der Dataflow-Vorlage.

Zusätzliche Frist für die Fehlerbehebung bei Ressourcen zur Fehlerbehebung

Wenn die oben aufgeführten Schritte zur Fehlerbehebung nach dem Ablauf einer festgelegten Frist weiterhin auftreten, können Sie mithilfe der folgenden Aufschlüsselung feststellen, ob Sie eine Supportanfrage öffnen müssen. Eine vollständige Liste der Supportanfragen finden Sie in der Tabelle zur Fehlerbehebung bei Latenzproblemen. Zusammenfassung: Bitte erstellen Sie ein Support-Ticket, wenn Folgendes zutrifft:

  • Eine hohe Latenz beim Google Front End, aber eine geringe Latenz bei der Spanner API
  • Eine hohe Anfragelatenz der Spanner API, aber eine niedrige Abfragelatenz

Weitere Informationen finden Sie in folgenden Ressourcen zur Fehlerbehebung: