Fehlerbehebung bei Fristüberschreitungen in Spanner

Auf dieser Seite finden Sie einen Überblick über Spanner-Fehler vom Typ „Deadline exceeded“ (Zeitlimit überschritten): Was sie sind, warum sie auftreten und wie Sie sie beheben können.

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

Ein Fehler vom Typ „Frist überschritten“ kann aus vielen verschiedenen Gründen auftreten, z. B. überlastete Spanner-Instanzen, nicht optimierte Schemas oder nicht optimierte Abfragen. Auf dieser Seite werden häufige Szenarien beschrieben, in denen ein Fehler aufgrund einer überschrittenen Frist auftritt. Außerdem finden Sie hier eine Anleitung zur Untersuchung und Behebung dieser Probleme.

Fristen und Wiederholungsstrategie von Spanner

Die Frist- und Wiederholungsphilosophie von Spanner unterscheidet sich von vielen anderen Systemen. In Spanner sollten Sie ein Zeitlimit als die maximale Zeitspanne angeben, in der eine Antwort nützlich ist. Es wird nicht empfohlen, eine künstlich kurze Frist festzulegen, um denselben Vorgang sofort noch einmal zu versuchen, da dies dazu führt, 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 beeinträchtigen:

  • Eine zu kurze Frist festlegen Das bedeutet, dass der Vorgang nicht gegen gelegentliche Anstiege der Tail-Latenz geschützt ist und nicht abgeschlossen werden kann, bevor das Zeitlimit überschritten wird. Legen Sie stattdessen eine Frist fest, die der maximalen Zeit entspricht, in der eine Antwort nützlich ist.

  • Wenn Sie eine zu lange Frist festlegen und den Vorgang vor Ablauf der Frist abbrechen. Dies führt zu Wiederholungsversuchen und verschwendeter Arbeit bei jedem Versuch. Insgesamt kann dies zu einer erheblichen zusätzlichen Belastung Ihrer Instanz führen.

Was ist ein Fehler wegen Überschreitung der Frist?

Wenn Sie eine der Spanner-Clientbibliotheken verwenden, kümmert sich die zugrunde liegende gRPC-Ebene um die Kommunikation, das Marshaling, das Unmarshaling und die Durchsetzung von Fristen. Mit Zeitlimits können Sie in Ihrer Anwendung angeben, wie lange gewartet werden soll, bis eine Anfrage abgeschlossen ist, bevor sie mit dem Fehler „Zeitlimit überschritten“ beendet wird.

In der Anleitung zur Zeitüberschreitungskonfiguration wird gezeigt, wie Sie Fristen (oder Zeitüberschreitungen) in den einzelnen unterstützten Spanner-Clientbibliotheken angeben können. Die Spanner-Clientbibliotheken verwenden die Standardeinstellungen für Zeitlimits und Wiederholungsversuche, die in den folgenden Konfigurationsdateien definiert sind:

Weitere Informationen zu gRPC-Deadlines finden Sie unter gRPC and Deadlines.

Häufige Fehler aufgrund überschrittener Fristen untersuchen und beheben

DEADLINE_EXCEEDED-Fehler können bei den folgenden Problemtypen auftreten:

Probleme mit der Data Access API

Eine Spanner-Instanz muss für Ihre spezifischen Arbeitslasten richtig konfiguriert sein, um Probleme mit der Data Access API zu vermeiden. In den folgenden Abschnitten wird beschrieben, wie Sie verschiedene Probleme mit Data Access APIs untersuchen und beheben.

CPU-Auslastung der Spanner-Instanz prüfen

Die Anfragelatenz kann erheblich steigen, wenn die CPU-Auslastung den empfohlenen Grenzwert für einen fehlerfreien Betrieb überschreitet. Sie können die Spanner-CPU-Auslastung in der Monitoring-Konsole in der Google Cloud -Konsole prüfen. Sie können auch Benachrichtigungen basierend auf der CPU-Auslastung der Instanz erstellen.

Lösung

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

Aufschlüsselung der End-to-End-Latenz der Anfrage ansehen

Wenn eine Anfrage vom Client zu den Spanner-Servern und zurück gesendet wird, sind mehrere Netzwerk-Hops erforderlich: von der Clientbibliothek zum Google Front End (GFE), vom GFE zum Spanner API-Frontend und schließlich vom Spanner API-Frontend zur Spanner-Datenbank. Wenn in einer dieser Phasen Netzwerkprobleme auftreten, werden möglicherweise Fehler vom Typ „Frist überschritten“ angezeigt.

Die Latenz kann in jeder Phase erfasst werden. Weitere Informationen finden Sie unter Latenzpunkte in einer Spanner-Anfrage. Informationen dazu, wo Latenz in Spanner auftritt, finden Sie unter Ermitteln, wo Latenz in Spanner auftritt.

Lösung

Sobald Sie die Aufschlüsselung der Latenz erhalten haben, können Sie Messwerte verwenden, um die Latenz zu diagnostizieren, die Ursachen zu ermitteln und Lösungen zu finden.

Probleme mit der Data API

Bestimmte nicht optimale Nutzungsmuster der Data API von Spanner können zu Fehlern aufgrund von überschrittenen Zeitlimits führen. In diesem Abschnitt finden Sie Richtlinien dazu, wie Sie nach diesen nicht optimalen Nutzungsmustern suchen können.

Nach ressourcenintensiven Abfragen suchen

Wenn Sie versuchen, rechenintensive Abfragen auszuführen, die nicht innerhalb des konfigurierten Zeitlimits in den Clientbibliotheken ausgeführt werden, kann dies zu einem Fehler wegen Überschreitung des Zeitlimits führen. Beispiele für ressourcenintensive Abfragen sind unter anderem vollständige Scans einer großen Tabelle, Cross-Joins über mehrere große Tabellen oder die Ausführung einer Abfrage mit einem Prädikat für eine Nicht-Schlüsselspalte (ebenfalls ein vollständiger Tabellenscan).

Sie können teure Abfragen in der Abfragestatistiktabelle und der Transaktionsstatistiktabelle untersuchen. Diese Tabellen enthalten Informationen zu langsam ausgeführten 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 Ausführungspläne für Abfragen generieren, um genauer zu untersuchen, wie Ihre Abfragen ausgeführt werden.

Lösung

Best Practices für SQL-Abfragen Sie können auch die Daten aus den oben genannten Statistiktabellen und Ausführungsplänen verwenden, um Ihre Abfragen zu optimieren und Schemaänderungen an Ihren Datenbanken vorzunehmen. Mit diesen Best Practices lässt sich die Ausführungszeit der Anweisungen verkürzen, wodurch sich möglicherweise die Fehler aufgrund von überschrittenen Fristen vermeiden lassen.

Auf Konflikte durch Sperren prüfen

Für Spanner-Transaktionen müssen Sperren abgerufen werden, damit sie per Commit übertragen werden können. Anwendungen mit hohem Durchsatz können dazu führen, dass Transaktionen um dieselben Ressourcen konkurrieren. Dies führt zu längeren Wartezeiten für das Abrufen der Sperren und beeinträchtigt die Gesamtleistung. Dies kann dazu führen, dass Fristen für Lese- oder Schreibanfragen überschritten werden.

Die Ursache für Lese-/Schreibtransaktionen mit hoher Latenz können Sie mithilfe der Tabelle mit Sperrstatistiken und des folgenden Blogposts ermitteln. In der Tabelle mit den Sperrstatistiken finden Sie die Zeilenschlüssel mit den längsten Wartezeiten für Sperren.

In diesem Leitfaden zur Fehlerbehebung bei Sperrkonflikten wird beschrieben, wie Sie die Transaktionen finden, die auf die Spalten zugreifen, die am Sperrkonflikt beteiligt sind. Sie können auch mithilfe des Leitfadens zur Fehlerbehebung mit Transaktions-Tags herausfinden, welche Transaktionen an einem Sperrkonflikt beteiligt sind.

Lösung

Wenden Sie diese Best Practices an, um Sperrkonflikte zu reduzieren. Verwenden Sie außerdem schreibgeschützte Transaktionen für einfache Leseanwendungsfälle, um Sperrkonflikte mit den Schreibvorgängen zu vermeiden. Lese-Schreib-Transaktionen sollten nur für Schreibvorgänge oder gemischte Lese-Schreib-Arbeitsabläufe verwendet werden. Wenn Sie diese Schritte ausführen, sollte sich die Latenz bei der Ausführung von Transaktionen insgesamt verbessern und die Anzahl der Fehler aufgrund überschrittener Fristen verringern.

Nach nicht optimierten Schemas suchen

Bevor Sie ein optimales Datenbankschema für Ihre Spanner-Datenbank entwerfen, sollten Sie die Arten von Abfragen berücksichtigen, die in Ihrer Datenbank ausgeführt werden. Suboptimale Schemas können bei der Ausführung bestimmter Abfragen zu Leistungsproblemen führen. Diese Leistungsprobleme können dazu führen, dass Anfragen nicht innerhalb der konfigurierten Frist abgeschlossen werden.

Lösung

Das optimale Schemadesign hängt von den Lese- und Schreibvorgängen ab, die in Ihrer Datenbank ausgeführt werden. Die Anleitungen zu Best Practices für Schemadesign und Best Practices für SQL sollten unabhängig von den Schemadetails befolgt werden. Wenn Sie diese Anleitungen befolgen, vermeiden Sie die häufigsten Probleme beim Schemadesign. Einige andere Hauptursachen für eine schlechte Leistung sind auf die Auswahl der Primärschlüssel, das Tabellenlayout (siehe Verschachtelte Tabellen für schnelleren Zugriff verwenden), das Schemadesign (siehe Schema für Leistung optimieren) und die Leistung des in Ihrer Spanner-Instanz konfigurierten Knotens (siehe Leistungsübersicht für Spanner) zurückzuführen.

Hotspots prüfen

Da Spanner eine verteilte Datenbank ist, muss beim Schemadesign darauf geachtet werden, Hotspots zu vermeiden. Wenn Sie beispielsweise monoton steigende Spalten erstellen, wird die Anzahl der Splits begrenzt, mit denen Spanner die Arbeitslast gleichmäßig verteilen kann. Diese Engpässe können zu Zeitüberschreitungen führen. Mit Key Visualizer können Sie auch Leistungsprobleme beheben, die durch Hotspots verursacht werden.

Lösung

Sehen Sie sich zuerst die Lösungen im vorherigen Abschnitt Nach nicht optimierten Schemas suchen an, um dieses Problem zu beheben. Gestalten Sie Ihr Datenbankschema neu und verwenden Sie verschachtelte Indexe, um Indexe zu vermeiden, die Hotspots verursachen könnten. Wenn das Problem durch diese Schritte nicht behoben wird, finden Sie hier weitere Informationen. Vermeiden Sie außerdem suboptimale Traffic-Muster wie Lesevorgänge in großen Bereichen, die eine lastbasierte Aufteilung verhindern können.

Auf falsch konfigurierte Zeitüberschreitungen prüfen

Die Clientbibliotheken bieten angemessene Standard-Timeouts für alle Anfragen in Spanner. Diese Standardkonfigurationen müssen jedoch möglicherweise an Ihre spezifische Arbeitslast angepasst werden. Es lohnt sich, die Kosten Ihrer Anfragen im Blick zu behalten und die Fristen an Ihren spezifischen Anwendungsfall anzupassen.

Lösung

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

Probleme mit Admin APIs

Admin API-Anfragen sind im Vergleich zu Data API-Anfragen teure Vorgänge. Administratoranfragen wie CreateInstance, CreateDatabase oder CreateBackups können viele Sekunden dauern, bis eine Antwort zurückgegeben wird. Spanner-Clientbibliotheken legen für Administratoranfragen für Instanzen und Datenbanken eine Frist von 60 Minuten fest. So wird sichergestellt, dass der Server die Anfrage abschließen kann, bevor der Client es noch einmal versucht oder ein Fehler auftritt.

Lösung

Wenn Sie die Google Spanner-Clientbibliothek für den Zugriff auf die Administrator-API verwenden, achten Sie darauf, dass die Clientbibliothek aktualisiert ist und die neueste Version verwendet. Wenn Sie über eine von Ihnen erstellte Clientbibliothek direkt auf die Spanner API zugreifen, dürfen Sie für Ihre Instanz- und Datenbank-Administratoranfragen keine aggressiveren Fristeinstellungen als die Standardeinstellungen (60 Minuten) verwenden.

Google Cloud Probleme mit der Console

Abfragen, die über die Spanner Studio-Seite der Google Cloud Konsole ausgegeben werden, dürfen nicht länger als fünf Minuten dauern. Wenn Sie eine aufwendige Abfrage erstellen, deren Ausführung länger als fünf Minuten dauert, wird die folgende Fehlermeldung angezeigt:

Screenshot der Fehlermeldung „Frist überschritten“ in der Google Cloud Console

Das Backend bricht die fehlgeschlagene Anfrage ab und die Transaktion wird bei Bedarf zurückgesetzt.

Lösung

Sie können die Abfrage mithilfe des Leitfadens zu Best Practices für SQL-Abfragen neu schreiben.

Dataflow-Probleme

In Apache Beam beträgt die Standardkonfiguration für das Zeitlimit zwei Stunden für Lesevorgänge und 15 Sekunden für Commit-Vorgänge. Diese Konfigurationen ermöglichen längere Vorgänge als die Standalone-Clientbibliotheks-Timeouts. Es ist jedoch weiterhin möglich, dass ein Zeitüberschreitungs- und Fristüberschreitungsfehler auftritt, wenn die Arbeitselemente zu groß sind. Bei Bedarf können Sie die Konfiguration für das Apache Beam-Commit-Zeitlimit anpassen.

Lösung

Wenn in den Schritten ReadFromSpanner / Execute query / Read from Spanner / Read from Partitions ein Fehler aufgrund einer überschrittenen Frist auftritt, sehen Sie in der Tabelle mit Abfragestatistiken nach, bei welcher Abfrage eine große Anzahl von Zeilen gescannt wurde. Ändern Sie diese Abfragen dann, um die Ausführungszeit zu verkürzen.

Ein weiteres Beispiel für einen Dataflow-Fehler aufgrund einer überschrittenen Frist ist in der folgenden Ausnahmemeldung zu sehen:

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)

Dieses Zeitlimit wurde überschritten, weil die Arbeitsvorgänge zu groß sind. Im vorherigen Beispiel können die folgenden beiden Empfehlungen helfen. Als Erstes kannst du versuchen, den Shuffle-Dienst zu aktivieren, falls er noch nicht aktiviert ist. Zweitens können Sie versuchen, die Konfigurationen in den Lesevorgängen Ihrer Datenbank anzupassen, z. B. maxPartitions und partitionSizeBytes. Weitere Informationen finden Sie unter PartitionOptions. Ein Beispiel dafür finden Sie in dieser Dataflow-Vorlage.

Zusätzliche Ressourcen zur Fehlerbehebung bei überschrittenen Fristen

Wenn nach Abschluss der Schritte zur Fehlerbehebung weiterhin ein DEADLINE_EXCEEDED-Fehler angezeigt wird, erstellen Sie eine Supportanfrage, wenn einer der folgenden Fälle eintritt:

  • Hohe Google Front End-Latenz, aber niedrige Spanner API-Anfragelatenz
  • Hohe Latenz der Spanner API-Anfrage, aber niedrige Abfragelatenz

Weitere Informationen zur Fehlerbehebung findest du hier: