Fehler bei Cloud Spanner-Zeitüberschreitung überschritten

Diese Seite bietet einen Überblick über die Fehler, die bei Cloud Spanner-Zeitüberschreitungen aufgetreten sind: welche Fehler, 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 gibt an, dass innerhalb des konfigurierten Zeitlimits keine Antwort eingegangen ist.

Ein Fehler zum Überschreiten einer Frist kann aus vielen verschiedenen Gründen auftreten, z. B. mit überlasteten Spanner-Instanzen, nicht optimierten Schemas oder nicht optimierten Abfragen. Auf dieser Seite werden häufige Szenarien beschrieben, in denen eine Frist überschritten wurde. Außerdem wird beschrieben, wie Sie diese Probleme untersuchen und beheben können.

Die Deadline von Cloud Spanner und die Wiederholungsphilosophie

Die Deadline- und Wiederholungsphilosophie von Spanner unterscheidet sich von vielen anderen Systemen. In Spanner sollten Sie ein Zeitlimit festlegen, das für die maximale Zeitspanne gilt, in der eine Antwort nützlich ist. Es wird nicht empfohlen, eine künstlich kurze Frist für den sofortigen erneuten Versuch festzulegen, da dies zu Situationen führen kann, in denen Vorgänge nie abgeschlossen werden. In diesem Kontext werden die folgenden Strategien und Vorgänge nicht empfohlen, da sie kontraproduktiv sind und das interne Wiederholungsverhalten von Spanner verhindern:

Das Zeitlimit ist zu kurz. Dies bedeutet, dass der Vorgang gegen eine gelegentliche Erhöhung der Extremwertlatenz nicht resistent ist und nicht vor einer Zeitüberschreitung abgeschlossen werden kann. Legen Sie stattdessen eine Frist fest, die die maximale Zeitspanne ist, in der eine Antwort nützlich ist.
Wenn Sie eine Frist festlegen, die zu lang ist, und den Vorgang vor Ablauf der Frist abbrechen. 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 ein Fehler, der die Frist überschritten hat?

Wenn Sie eine der Spanner-Clientbibliotheken verwenden, übernimmt die zugrunde liegende gRPC-Ebene die Kommunikation, Marshalling, Unmarshalling und die Erzwingung von Fristen. Mithilfe von Fristen kann die Anwendung angeben, wie lange sie warten soll, bis eine Anfrage abgeschlossen ist, bevor die Anfrage mit dem Fehler für das Zeitlimit beendet wird.

In der Anleitung zur Zeitüberschreitung sehen Sie, wie Sie in den unterstützten Spanner-Clientbibliotheken Fristen (oder Zeitüberschreitungen) festlegen können. Die Spanner-Clientbibliotheken verwenden die Standardeinstellungen für Zeitlimits und Wiederholungsrichtlinien, die in den folgenden Konfigurationsdateien definiert sind:

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

Häufige Fristüberschreitungen untersuchen und beheben

Probleme mit der Data Access API

Eine Spanner-Instanz muss entsprechend für Ihre spezifischen Arbeitslasten konfiguriert werden, um Probleme mit der Datenzugriffs-API zu vermeiden. In den folgenden Abschnitten wird beschrieben, wie Sie verschiedene Probleme beim API für den Datenzugriff untersuchen und beheben können.

CPU-Auslastung der Spanner-Instanz prüfen

Die Anfragelatenz kann erheblich erhöht werden, wenn die CPU-Auslastung den empfohlenen Schwellenwert für Intaktheit überschreitet. Sie können Ihre Spanner-CPU-Auslastung in der Monitoringkonsole prüfen, die in der Google Cloud Console bereitgestellt wird. Sie können auch Benachrichtigungen erstellen, die auf der CPU-Auslastung der Instanz basieren.

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 an die Spanner-Server und zurück gesendet wird, müssen mehrere Netzwerk-Hops vorgenommen werden: von der Clientbibliothek zum Google Front End (GFE), vom GFE zum Front-End der Spanner API und schließlich vom Front-End der Spanner API zur Datenbank. Wenn in einer dieser Phasen Netzwerkprobleme auftreten, werden möglicherweise Fehler wegen Zeitüberschreitung überschritten.

Es ist möglich, die Latenz in jeder Phase zu erfassen (siehe Latenzleitfaden). Weitere Informationen zur Verwendung der Diagnoseanleitung finden Sie unter Latenzprobleme diagnostizieren.

Lösung

Nachdem Sie die Latenzaufschlüsselung abgerufen und das Latenzproblem diagnostiziert haben, können Sie anhand dieser Anleitung zur Fehlerbehebung bei Latenzproblemen die Ursache der Latenz ermitteln und den Grund dafür verstehen.

Probleme mit der Data API

Bestimmte nicht optimale Nutzungsmuster der Daten-API von Spanner können zu einer Fristüberschreitung führen. Dieser Abschnitt enthält Richtlinien zum Prüfen dieser nicht optimalen Nutzungsmuster.

Auf teure Abfragen prüfen

Der Versuch, teure Abfragen auszuführen, die nicht innerhalb der konfigurierten Zeitüberschreitungsfrist in den Clientbibliotheken ausgeführt werden, kann zu einem Fehler beim Überschreiten einer Frist führen. Beispiele für teure Abfragen sind unter anderem vollständige Scans einer großen Tabelle, Cross-Joins über mehrere große Tabellen oder eine Abfrageausführung mit einem Prädikat über eine Nicht-Schlüsselspalte (auch ein vollständiger Tabellenscan).

Sie können teure Abfragen mit der Abfragestatistiktabelle und der Transaktionsstatistiktabelle prüfen. Diese Tabellen enthalten Informationen zu langsamen Abfragen und Transaktionen, z. B. die durchschnittliche Anzahl der gelesenen Zeilen, die durchschnittliche Anzahl gelesener Byte und die durchschnittliche Anzahl der gescannten Zeilen. Darüber hinaus können Sie Pläne für die Abfrageausführung generieren, um die Ausführung Ihrer Abfragen weiter zu untersuchen.

Lösung

Weitere Informationen zur Optimierung von Abfragen finden Sie in den Best Practices für SQL-Abfragen. Sie können auch die Daten verwenden, die Sie über die oben genannten Statistiktabellen und Ausführungspläne erhalten haben, 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 verkürzen, wodurch möglicherweise das Zeitlimit überschritten wird.

Auf Sperrungen prüfen

Spanner-Transaktionen müssen Bindungen zum Commit erhalten. Anwendungen, die mit hohem Durchsatz ausgeführt werden, können dazu führen, dass Transaktionen um dieselben Ressourcen konkurrieren. Dies führt zu längeren Wartezeiten beim Erhalt der Sperren und beeinträchtigt die Gesamtleistung. Dies kann zu Fristen für Lese- oder Schreibanfragen führen.

Die Ursache für Lese-Schreib-Transaktionen 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 höchsten Wartezeiten bei der Sperrung.

In dieser Anleitung zur Fehlerbehebung bei Sperrkonflikten wird erläutert, wie Sie die Transaktionen finden, die auf die Spalten zugreifen, die vom Sperrkonflikt betroffen sind. Sie können auch im Leitfaden zur Fehlerbehebung für Transaktions-Tags sehen, welche Transaktionen an einem Sperrkonflikt beteiligt sind.

Lösung

Wenden Sie diese Best Practices an, um Sperrenkonflikte zu vermeiden. Verwenden Sie außerdem schreibgeschützte Transaktionen für einfache Leseanwendungsfälle, um Sperrkonflikte mit Schreibvorgängen zu vermeiden. Lese-Schreib-Transaktionen sollten für Schreibvorgänge oder gemischte Lese-/Schreib-Workflows reserviert sein. Das Ausführen der folgenden Schritte sollte die Gesamtlatenz der Transaktionsausführungszeit verbessern und die Fristen für Fehler, die überschritten wurden, verkürzen.

Nach nicht optimierten Schemas suchen

Bevor Sie ein optimales Datenbankschema für Ihre Spanner-Datenbank entwerfen, sollten Sie sich überlegen, welche Arten von Abfragen in Ihrer Datenbank ausgeführt werden. Suboptimale Schemas können beim Ausführen von 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 Best Practices für das Schemadesign und die Best Practices für SQL sollten unabhängig von den Schemaspezifikationen eingehalten werden. Mit diesen Anleitungen vermeiden Sie die häufigsten Probleme mit dem Schemadesign. Andere Ursachen für schwache Leistung werden Ihrer Auswahl von Primärschlüsseln, dem Tabellenlayout (siehe verschränkte Tabellen für einen schnelleren Zugriff), dem Schemadesign (siehe Optimierung des Schemas für die Leistung) und der Leistung des Knotens in Ihrer Spanner-Instanz (siehe Regionale Limits oder multiregionale Limits) zugeordnet.

Auf Hotspots prüfen

Da es sich bei Spanner um eine verteilte Datenbank handelt, muss das Schemadesign Hotspots verhindern. Durch das Erstellen kontinuierlich ansteigender 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 zur Lösung dieses Problems die im vorherigen Abschnitt Auf nicht optimierte Schemas prüfen genannten Lösungen. Überarbeiten Sie Ihr Datenbankschema und verwenden Sie verschränkte Indexe, um Indexe zu vermeiden, die zu Heißlaufen führen können. Wenn das Problem durch diese Schritte nicht behoben wird, lesen Sie die Anleitung Primärschlüssel zur Vermeidung von Hotspots auswählen. Schließlich sollten Sie suboptimale Traffic-Muster wie z. B. große Bereichslesevorgänge vermeiden, die eine lastbasierte Aufteilung verhindern könnten.

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 zu beobachten und die Fristen entsprechend Ihrem speziellen Anwendungsfall anzupassen.

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 Wiederholungsleitfaden). Es wird jedoch nicht empfohlen, aggressivere Zeitlimits als die Standardkonfigurationen zu verwenden. Wenn Sie das Zeitlimit ändern möchten, legen Sie es auf die tatsächliche Zeit fest, die die Anwendung 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, die die Anwendung bereit ist, da dies dazu führen würde, dass der Vorgang häufiger wiederholt wird.

Probleme mit der Admin API

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

Lösung

Wenn Sie mit der Google Spanner-Clientbibliothek auf die Admin API zugreifen, achten Sie darauf, dass die Clientbibliothek aktualisiert wurde und die neueste Version verwendet wird. Wenn Sie direkt über eine von Ihnen erstellte Clientbibliothek auf die Spanner API zugreifen, achten Sie darauf, dass für Ihre Instanz- und Datenbankadministratoren nicht strengere Fristen festgelegt sind als die Standardeinstellungen (60 Minuten).

Probleme mit der Google Cloud Console

Abfragen, die über die Abfrageseite der Google Cloud Console gesendet werden, 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 Fehlermeldung für das Zeitlimit der Cloud Console wurde überschritten

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

Lösung

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

Dataflow-Probleme

In Apache Beam beträgt die Standardzeitüberschreitungskonfiguration 2 Stunden für Lesevorgänge und 15 Sekunden für Commit-Vorgänge. Diese Konfigurationen ermöglichen im Vergleich zu den Zeitlimits für die eigenständige Clientbibliothek längere Vorgänge. Sie können jedoch weiterhin eine Zeitüberschreitung und eine Fristüberschreitung erhalten, wenn die Arbeitselemente zu groß sind. Derzeit kann die Commit-Zeitüberschreitung bei Apache Beam nur bei Bedarf angepasst werden.

Lösung

Wenn in den Schritten ReadFromSpanner / Execute query / Read from Cloud Spanner / Read from Partitions ein Fehler für das Zeitlimit überschritten wurde, sehen Sie in der Abfragestatistiktabelle nach, bei welcher Abfrage eine große Anzahl von Zeilen gescannt wurde. Ändern Sie dann diese Abfragen, um die Ausführungszeit zu reduzieren.

Ein weiteres Beispiel für einen Fehler bei Überschreiten von Dataflow-Zeitlimits 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)

Diese Zeitüberschreitung ist aufgetreten, weil die Aufgaben zu groß sind. Im obigen Beispiel können die folgenden beiden Empfehlungen helfen. Als Erstes können Sie versuchen, den Shuffle-Dienst zu aktivieren, falls er noch nicht aktiviert ist. Zweitens können Sie versuchen, die Konfigurationen im Lesevorgang Ihrer Datenbank zu optimieren, z. B. maxPartitions und partitionSizeBytes. Weitere Informationen dazu, wie Sie die Größe der Arbeitselemente reduzieren, finden Sie unter PartitionOptions. Ein Beispiel dafür finden Sie in dieser Dataflow-Vorlage.

Zusätzliches Zeitlimit für Ressourcen zur Fehlerbehebung überschritten

Wenn der Fehler nach Überschreiten der oben genannten Schritte zur Fehlerbehebung weiterhin auftritt, können Sie anhand der folgenden Aufschlüsselung ermitteln, ob Sie eine Supportanfrage öffnen müssen. Eine vollständige Liste der Supportanfragen finden Sie in der Tabelle zur Behebung von Latenzproblemen. Zusammenfassung: Bitte erstellen Sie in den folgenden Fällen ein Support-Ticket:

Eine hohe Latenz für das Google Front End, aber eine niedrige Latenz bei Spanner API-Anfragen
Eine hohe Latenz bei Anfragen über die Spanner API, aber eine niedrige Latenz bei Abfragen

Weitere Informationen finden Sie in den folgenden Ressourcen zur Fehlerbehebung: