Diese Seite bietet einen Überblick über Fehler bei Spanner-Zeitüberschreitungen: 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 keine Antwort
innerhalb des konfigurierten Zeitlimits empfangen wurde.
Ein Fehler, der zu einer Fristüberschreitung führt, kann viele verschiedene Gründe haben, z. B.: überlastete Spanner-Instanzen, nicht optimierte Schemas oder nicht optimiert Abfragen. Auf dieser Seite werden häufige Szenarien beschrieben, in denen ein Fehler aufgrund einer Fristüberschreitung beschrieben wird. und Sie erhalten einen Leitfaden zur Untersuchung und Lösung dieser Probleme.
Frist und Wiederholungsphilosophie von Spanner
Die Frist und Wiederholungsphilosophie von Spanner unterscheiden sich von vielen Systeme. 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 werden die folgenden Strategien und Vorgänge nicht empfohlen: sie sind kontraproduktiv und verhindern den internen Wiederholungsversuch von Spanner Verhalten:
Sie legen einen zu kurzen Termin fest. Das bedeutet, dass der Vorgang nicht sind widerstandsfähig gegen gelegentliche Anstiege der Extremwertlatenz und können erst abgeschlossen werden, eine Zeitüberschreitung auftritt. Legen Sie stattdessen einen Termin fest, der der maximalen Zeit entspricht, in der eine Antwort nützlich ist.
Festlegen einer zu langen Frist und Abbrechen des Vorgangs vor dem Frist überschritten wird. Dies führt zu Wiederholungen und vergeudeter Arbeit bei jedem Versuch. Insgesamt kann dies zu einer erheblichen zusätzlichen Belastung Ihrer Instanz führen.
Was ist der Fehler einer Fristüberschreitung?
Wenn Sie eine der Spanner-Clientbibliotheken verwenden, übernimmt die zugrunde liegende gRPC-Schicht Kommunikation, Marshalling, Unmarshalling, und Durchsetzung der Fristen. Fristen ermöglichen es Ihrer Anwendung, anzugeben, wie lange Er ist bereit, auf den Abschluss einer Anfrage zu warten, bevor sie beendet wird. mit dem Fehler, dass die Frist überschritten wurde.
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:
- spanner_grpc_service_config.json
- spanner_admin_instance_grpc_service_config.json
- spanner_admin_database_grpc_service_config.json
Weitere Informationen zu gRPC-Fristen finden Sie unter gRPC und Fristen.
So untersuchen und beheben Sie häufige Fehler bei Fristüberschreitungen
DEADLINE_EXCEEDED
-Fehler können bei den folgenden Problemtypen auftreten:
- Probleme mit der Data Access API
- Probleme mit der Data API
- Probleme mit der Admin API
- Probleme mit der Google Cloud Console
- Dataflow-Probleme
Probleme mit der Data Access API
Eine Spanner-Instanz muss entsprechend für Ihre um Probleme mit der Datenzugriffs-API zu vermeiden. 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 erheblich ansteigen, wenn die CPU-Auslastung den empfohlenen Schwellenwert für Intaktheit. Sie können die die Spanner-CPU-Auslastung in der Monitoring-Konsole in der Google Cloud Console bereitgestellt. Sie können auch Benachrichtigungen erstellen. basierend auf der CPU-Auslastung der Instanz ab.
Lösung
Schritte 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 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 Latenzaufschlüsselung erhalten haben, können Sie mit Messwerten die Latenz diagnostizieren, verstehen und Lösungen zu finden.
Probleme mit der Data API
Bestimmte nicht optimale Nutzungsmuster der Data API von Spanner Fehler wegen überschrittener Fristen verursachen. In diesem Abschnitt finden Sie Richtlinien dazu, wie Sie diese nicht optimalen Nutzungsmuster prüfen.
Teure Abfragen prüfen
Sie versuchen, teure Abfragen auszuführen, die nicht innerhalb des konfigurierten Zeitlimits ausgeführt werden Deadline in den Clientbibliotheken kann zum Fehler einer Fristüberschreitung führen. 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 teure Abfragen mithilfe der Abfragestatistiktabelle überprüfen. und die Tabelle mit den Transaktionsstatistiken. Diese Tabellen enthalten Informationen zu langsam laufenden Abfragen und Transaktionen, z. B. die durchschnittliche Anzahl der gelesenen Zeilen, die durchschnittlich gelesenen Byte 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 auch die Daten aus den oben genannten Statistiktabellen und Ausführungspläne, um Abfragen zu optimieren und Schemaänderungen vorzunehmen zu Ihren Datenbanken hinzufügen. 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 abrufen zu bestätigen. Bei Anwendungen mit hohem Durchsatz kann es dazu kommen, dass Transaktionen um dieselben Ressourcen konkurrieren. Dies führt zu längeren Wartezeiten für die Sperren und wirkt sich auf die Gesamtleistung aus. Dies kann zu einer Überschreitung der Fristen für alle Lese- oder Schreibanfragen verwendet.
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
Best Practices um Sperrenkonflikte zu 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.
Nach nicht optimierten Schemas suchen
Bevor Sie ein optimales Datenbankschema für Spanner entwerfen sollten Sie berücksichtigen, welche Abfragen ausgeführt werden, in Ihrer Datenbank. Suboptimale Schemas können bei der Ausführung zu Leistungsproblemen führen einige Suchanfragen. 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 Best Practices für das Schemadesign und SQL sollten Sie die Best Practices befolgen, Schema-Besonderheiten. Wenn Sie diese Leitfäden befolgen, vermeiden Sie die am häufigsten verwendeten Schemata Designprobleme. 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 das Verhindern von Hotspots berücksichtigt werden muss. Eine monotone Erstellung Durch Erhöhen der Spalten wird die Anzahl der Splits begrenzt, mit denen Sie arbeiten können, um die Arbeitslast gleichmäßig zu verteilen. Diese Engpässe können in Zeitüberschreitungen. Sie können auch den Key Visualizer verwenden, zur Behebung von durch Hotspots verursachten Leistungsproblemen.
Lösung
Lösungen finden Sie im vorherigen Abschnitt Auf nicht optimierte Seiten prüfen . um das Problem zu beheben. Gestalten Sie Ihre Datenbankschema und verschränkte Indexe verwenden um Indexe zu vermeiden, die ein Heißlaufen verursachen könnten. Wenn Sie diese Schritte ausführen, Informationen dazu, wie Sie das Problem beheben, finden Sie im Leitfaden zum Auswählen eines Primärschlüssels zur Vermeidung von Hotspots. Vermeiden Sie schließlich suboptimale Traffic-Muster wie z. B. Lesevorgänge mit großem Bereich, die möglicherweise eine lastbasierte Aufteilung verhindern.
Auf falsch konfigurierte Zeitüberschreitungen prüfen
Die Clientbibliotheken bieten angemessene Timeout-Standardwerte für alle Anfragen in Spanner. Diese Standardkonfigurationen müssen jedoch möglicherweise an Ihre spezifische Arbeitslast angepasst werden. Es lohnt sich, die Kosten Abfragen und die Anpassung der Fristen an Ihren spezifischen Anwendungsfall.
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, stellen Sie es auf den bereit ist, auf das Ergebnis zu warten. 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 kostenintensive Vorgänge.
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 wird sichergestellt, dass der Server die Möglichkeit hat,
, bevor der Client den Vorgang wiederholt oder 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.
Probleme mit der Google Cloud Console
Abfragen, die über die Spanner Studio-Seite in 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 ausgeführt wird, wird die folgende Fehlermeldung angezeigt:
Das Backend bricht die fehlgeschlagene Abfrage ab und die Transaktion wird möglicherweise zurückgesetzt wenn nötig.
Lösung
Sie können die Abfrage gemäß dem Leitfaden mit Best Practices für SQL-Abfragen neu schreiben.
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, wenn im Vergleich zu den Zeitlimits für die eigenständige Clientbibliothek. Es ist jedoch Es ist immer noch möglich, dass ein Fehler wegen Zeitüberschreitung und Zeitüberschreitung ausgegeben wird, wenn die Arbeitselemente sind zu groß. Bei Bedarf können Sie die Konfiguration für die Apache Beam-Commit-Zeitüberschreitung anpassen.
Lösung
Wenn in den Schritten ReadFromSpanner / Execute
query / Read from Spanner / Read from Partitions
ein Fehler auftritt, bei dem die Frist überschritten wurde, prüfen Sie die
Tabelle mit Abfragestatistiken
um herauszufinden, welche Abfrage eine große Anzahl von Zeilen gescannt hat. Passen Sie dann
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 zwei Empfehlungen hilfreich sein. Du kannst versuchen, den Zufallsmix-Dienst zu aktivieren, falls er noch nicht aktiviert ist. Zweitens können Sie versuchen,
Konfigurationen im Lesevorgang Ihrer Datenbank, z. B. maxPartitions
und
partitionSizeBytes
. Weitere Informationen findest du unter PartitionOptions
.
die Arbeitselementgröße zu reduzieren. Ein Beispiel dafür finden Sie in dieser Dataflow-Vorlage.
Zusätzliche Frist für die Fehlerbehebung bei Ressourcenüberschreitung
Wenn der Fehler DEADLINE_EXCEEDED
weiterhin angezeigt wird, nachdem Sie das
zur Fehlerbehebung, öffnen Sie eine Supportanfrage, wenn
die folgenden Szenarien:
- 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 unter den folgenden Links:
- Latenz in einer Spanner-Komponente mit OpenTelemetry untersuchen
- Fehlerbehebung bei Leistungsabfällen
- Ausgeführte Abfragen in Spanner analysieren, um Leistungsprobleme zu diagnostizieren