Fehlerbehebung bei Fehlern vom Typ „Spanner-Frist überschritten“

Auf dieser Seite finden Sie einen Überblick über Fehler vom Typ „Spanner-Frist ü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 eingegangen ist.

Ein Fehler vom Typ „Frist überschritten“ kann viele verschiedene Ursachen haben, z. B. überlastete Spanner-Instanzen, nicht optimierte Schemas oder nicht optimierte Abfragen. Auf dieser Seite werden häufige Szenarien beschrieben, in denen der Fehler „Frist überschritten“ auftritt, und es wird erläutert, wie Sie diese Probleme untersuchen und beheben können.

Frist und Wiederholungsphilosophie von Spanner

Die Deadline- und Wiederholungsphilosophie von Spanner unterscheidet sich von vielen anderen Systemen. In Spanner sollten Sie einen Zeitüberschreitungszeitraum als maximalen Zeitraum angeben, in dem eine Antwort nützlich ist. Es wird nicht empfohlen, ein künstlich kurzes Zeitlimit festzulegen, nur um denselben Vorgang sofort noch einmal zu wiederholen. Dies 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 untergraben:

  • Sie legen einen zu kurzen Termin fest. Das bedeutet, dass der Vorgang nicht gegen gelegentliche Schwankungen der Latenz am Ende der Warteschlange resistent ist und nicht abgeschlossen werden kann, bevor die Zeitüberschreitung eintritt. Legen Sie stattdessen einen Termin fest, der der maximalen Zeit entspricht, in der eine Antwort nützlich ist.

  • Sie legen eine zu lange Frist fest und brechen den Vorgang ab, bevor die Frist abgelaufen 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 ein Fehler vom Typ „Frist überschritten“?

Wenn Sie eine der Spanner-Clientbibliotheken verwenden, übernimmt die zugrunde liegende gRPC-Ebene die Kommunikation, Marshalling, Unmarshalling und die Durchsetzung von Fristen. Mit Fristen können Sie in Ihrer Anwendung angeben, wie lange auf den Abschluss einer Anfrage gewartet werden soll, bevor die Anfrage mit der Fehlermeldung „Frist überschritten“ beendet wird.

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

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

Häufige Fehlermeldungen zum Überschreiten des Termins 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 API für den Datenzugriff zu vermeiden. In den folgenden Abschnitten wird beschrieben, wie Sie verschiedene Probleme mit dem Datenzugriff über die API untersuchen und beheben.

CPU-Auslastung der Spanner-Instanz prüfen

Die Anfragelatenz kann erheblich ansteigen, wenn die CPU-Auslastung den empfohlenen Grenzwert für eine ordnungsgemäße Auslastung überschreitet. Sie können die Spanner-CPU-Auslastung in der Monitoring Console 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 Verringern der CPU-Auslastung einer Instanz finden Sie unter CPU-Auslastung reduzieren.

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

Wenn eine Anfrage vom Client zu Spanner-Servern und zurück geleitet 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 Fehlermeldungen zum Überschreiten des Termins angezeigt.

Die Latenz kann in jeder Phase erfasst werden. Weitere Informationen finden Sie unter Latenzausschläge in einer Spanner-Anfrage. Informationen dazu, wo in Spanner Latenz auftritt, finden Sie unter Herausfinden, wo in Spanner Latenz auftritt.

Lösung

Sobald Sie die Aufschlüsselung der Latenz haben, können Sie Messwerte verwenden, um die Latenz zu diagnostizieren, die Ursache 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 führen, wenn das Zeitlimit überschritten wird. In diesem Abschnitt finden Sie Richtlinien dazu, wie Sie diese nicht optimalen Nutzungsmuster prüfen können.

Teure Abfragen prüfen

Wenn Sie versuchen, ressourcenintensive Abfragen auszuführen, die nicht innerhalb des konfigurierten Zeitlimits in den Clientbibliotheken ausgeführt werden, kann dies zu einem Fehler führen, dass das Zeitlimit überschritten wurde. Beispiele für teure Abfragen sind unter anderem vollständige Scans einer großen Tabelle, Kreuzjoins über mehrere große Tabellen oder die Ausführung einer Abfrage mit einem Prädikat für eine Nichtschlüsselspalte (auch ein vollständiger Tabellenscan).

Sie können sich teure Abfragen in der Tabelle mit Abfragestatistiken und in der Tabelle mit Transaktionsstatistiken ansehen. Diese Tabellen enthalten Informationen zu langsam laufenden Abfragen und Transaktionen, z. B. die durchschnittliche Anzahl der gelesenen Zeilen, die durchschnittlich gelesenen Bytes und die durchschnittliche Anzahl der gescannten Zeilen. Außerdem können Sie Abfrageausführungspläne generieren, um die Ausführung Ihrer Abfragen genauer zu untersuchen.

Lösung

Informationen zum Optimieren von Abfragen finden Sie im Leitfaden zu Best Practices für SQL-Abfragen. Sie können die Daten aus den zuvor erwähnten Statistiktabellen und die Ausführungspläne auch 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 reduzieren und möglicherweise die Fehlermeldung „Termin überschritten“ vermeiden.

Auf Sperrkonflikte prüfen

Spanner-Transaktionen müssen Sperren erwerben, um Commits auszuführen. Wenn Anwendungen mit hohem Durchsatz ausgeführt werden, kann es dazu führen, dass Transaktionen um dieselben Ressourcen konkurrieren. Dies führt zu einer längeren Wartezeit für die Sperren und wirkt sich auf die Gesamtleistung aus. Dies kann dazu führen, dass Fristen für Lese- oder Schreibanfragen überschritten werden.

Die Ursache für Lese-/Schreibtransaktionen mit hoher Latenz finden Sie in der Tabelle mit Sperrstatistiken und im folgenden Blogpost. In der Tabelle mit den Sperrstatistiken finden Sie die Zeilenschlüssel mit den längsten Sperrwartezeiten.

In diesem Leitfaden zur Fehlerbehebung bei Sperrkonflikten wird beschrieben, wie Sie die Transaktionen finden, die auf die Spalten zugreifen, die am Sperrkonflikt beteiligt sind. Im Leitfaden zur Fehlerbehebung mit Transaktions-Tags erfahren Sie außerdem, welche Transaktionen an einem Sperrkonflikt beteiligt sind.

Lösung

Mit diesen Best Practices können Sie Sperrkonflikte reduzieren. Verwenden Sie außerdem schreibgeschützte Transaktionen für Anwendungsfälle mit einfachen Lesevorgängen, um Sperrkonflikte mit den Schreibvorgängen zu vermeiden. Die Verwendung von Lese-Schreib-Transaktionen sollte auf Schreibvorgänge oder gemischte Lese-Schreib-Workflows beschränkt werden. Wenn Sie diese Schritte ausführen, sollte sich die Gesamtlatenz der Transaktionsausführung verbessern und die Anzahl der Fehler, dass die Frist überschritten wurde, verringern.

Nicht optimierte Schemas prüfen

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. Nicht optimale Schemas können bei der Ausführung einiger 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 in Ihrer Datenbank ab. Die Anleitungen zu Best Practices für das Schemadesign und Best Practices für SQL sollten unabhängig von den Schemaspezifikationen befolgt werden. Wenn Sie diese Anleitungen befolgen, vermeiden Sie die häufigsten Probleme beim Schemadesign. Weitere Ursachen für eine schlechte Leistung sind die Auswahl der Primärschlüssel, das Tabellenlayout (siehe Verschachtelte Tabellen für schnelleren Zugriff verwenden), das Schemadesign (siehe Schema für die Leistung optimieren) und die Leistung des Knotens, der in Ihrer Spanner-Instanz konfiguriert ist (siehe Spanner-Leistung – Übersicht).

Hotspots prüfen

Da Spanner eine verteilte Datenbank ist, muss das Schemadesign Hotspots verhindern. Wenn Sie beispielsweise monoton ansteigende Spalten erstellen, wird die Anzahl der Teilungen 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 dem Key Visualizer Leistungsprobleme beheben, die durch Hotspots verursacht werden.

Lösung

Lesen Sie den Abschnitt Nach nicht optimierten Schemas suchen, um dieses Problem zu beheben. Überarbeiten Sie Ihr Datenbankschema und verwenden Sie verschränkte Indexe, um Indexe zu vermeiden, die zu Hotspots führen können. Wenn sich das Problem dadurch nicht beheben lässt, lesen Sie den Leitfaden zum Auswählen eines Primärschlüssels zur Vermeidung von Hotspots. Vermeiden Sie außerdem suboptimale Traffic-Muster wie Lesevorgänge mit großem Bereich, die eine lastbasierte Aufteilung verhindern können.

Auf falsch konfigurierte Zeitüberschreitungen prüfen

Die Clientbibliotheken bieten angemessene Standardzeitüberschreitungen 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 Abfragen im Blick zu behalten und die Fristen so anzupassen, dass sie zu Ihrem jeweiligen Anwendungsfall passen.

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, kürzere Zeitüberschreitungen als die Standardzeitüberschreitungen 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 niemals ein Zeitlimit festlegen, das kürzer ist als die tatsächliche Zeit, zu der die Anwendung bereitsteht, 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 kostenintensiver. Bei Administratoranfragen wie CreateInstance, CreateDatabase oder CreateBackups kann es einige Sekunden dauern, bis eine Antwort zurückgegeben wird. Spanner-Clientbibliotheken legen eine Frist von 60 Minuten sowohl für Instanz- als auch für Datenbank-Administratoranfragen fest. So soll sichergestellt werden, dass der Server die Möglichkeit hat, die Anfrage abzuschließen, bevor der Client noch einmal versucht, sie zu senden oder sie fehlschlägt.

Lösung

Wenn Sie die Spanner-Clientbibliothek von Google für den Zugriff auf die Administrator API verwenden, prüfen Sie, ob die Clientbibliothek auf dem neuesten Stand ist. Wenn Sie direkt über eine von Ihnen erstellte Clientbibliothek auf die Spanner API zugreifen, dürfen die Fristeinstellungen nicht kürzer sein als die Standardeinstellungen (60 Minuten) für Administratoranfragen für Ihre Instanz und Datenbank.

Google Cloud -Konsolenprobleme

Abfragen, die über die Seite „Spanner Studio“ der Google Cloud -Console gesendet werden, dürfen maximal fünf Minuten dauern. Wenn Sie eine teure Abfrage erstellen, die mehr als fünf Minuten dauert, wird die folgende Fehlermeldung angezeigt:

Screenshot der Fehlermeldung „Console deadline exceeded“ (Frist für die Console abgelaufen) in der Google Cloud

Das Backend bricht die fehlgeschlagene Abfrage ab und die Transaktion wird bei Bedarf rückgängig gemacht.

Lösung

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

Dataflow-Probleme

In Apache Beam beträgt die Standardzeitüberschreitung zwei Stunden für Lesevorgänge und 15 Sekunden für Commit-Vorgänge. Diese Konfigurationen ermöglichen längere Vorgänge im Vergleich zu den Zeitüberschreitungen für Fristen der eigenständigen Clientbibliothek. Es ist jedoch möglich, dass ein Fehler auftritt, wenn die Zeitüberschreitung erreicht oder der Termin überschritten wird, weil die Arbeitselemente zu groß sind. Bei Bedarf können Sie die Konfiguration für das Apache Beam-Commit-Timeout anpassen.

Lösung

Wenn in Schritt ReadFromSpanner / Execute query / Read from Spanner / Read from Partitions der Fehler „Zeitlimit überschritten“ auftritt, sehen Sie in der Tabelle mit Abfragestatistiken nach, bei welcher Abfrage eine große Anzahl von Zeilen gescannt wurde. Ändern Sie dann solche Abfragen, um die Ausführungszeit zu reduzieren.

Ein weiteres Beispiel für einen Fehler vom Typ „Dataflow-Frist überschritten“ 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)

Das Zeitlimit wurde erreicht, weil die Arbeitselemente zu groß sind. Im vorherigen Beispiel könnten die folgenden beiden Empfehlungen hilfreich sein. Versuchen Sie zuerst, den Zufallsmix-Dienst zu aktivieren, falls er noch nicht aktiviert ist. Zweitens können Sie versuchen, die Konfigurationen für das Lesen Ihrer Datenbank anzupassen, z. B. maxPartitions und partitionSizeBytes. Weitere Informationen finden Sie unter PartitionOptions, um die Größe des Arbeitselements zu reduzieren. Ein Beispiel dazu finden Sie in dieser Dataflow-Vorlage.

Ressourcen zur Fehlerbehebung bei überschrittener Frist

Wenn der Fehler DEADLINE_EXCEEDED nach der Fehlerbehebung weiterhin angezeigt wird, erstelle bitte einen Supportfall, wenn eines der folgenden Szenarien zutrifft:

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

Weitere Informationen zur Fehlerbehebung finden Sie in den folgenden Artikeln: