Fehlerbehebung bei überschrittenen Cloud Spanner-Zeitlimits

Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Auf dieser Seite erhalten Sie einen Überblick über die Fehler, die bei Cloud Spanner-Zeitlimits überschritten wurden: Informationen zu den Ursachen, zu den auftretenden Fehlern und zur Fehlerbehebung.

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 eingegangen ist.

Dieser Fehler kann aus vielen verschiedenen Gründen auftreten, z. B. wegen überlasteter Spanner-Instanzen, nicht optimierter 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.

Cloud Spanner-Philosophie für Deadlines und Wiederholungen

Die Deadline- und Wiederholungsphilosophie von Spanner unterscheidet sich von vielen anderen Systemen. In Spanner sollten Sie eine Zeitüberschreitungsfrist als maximale Zeitspanne angeben, in der eine Antwort nützlich ist. Es wird nicht empfohlen, eine künstlich kurze Frist festzulegen, in der derselbe Vorgang noch einmal wiederholt wird, 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. Daher ist der Vorgang nicht widerstandsfähig gegenüber gelegentlichen Extremwertlatenzen und kann nicht vor einer Zeitüberschreitung abgeschlossen werden. Legen Sie stattdessen eine Frist fest, die der maximalen Dauer entspricht, in der eine Antwort nützlich ist.

  • Eine zu lange Frist festlegen und den Vorgang abbrechen, bevor die Frist überschritten wird. Dies führt zu Wiederholungsversuchen und verschwendeter Arbeit bei jedem Versuch. Insgesamt kann dies jedoch zu einer erheblichen zusätzlichen Belastung Ihrer Instanz führen.

Was ist ein Fehler wegen Zeitüberschreitung?

Wenn Sie eine der Spanner-Clientbibliotheken verwenden, übernimmt die zugrunde liegende gRPC-Ebene die Kommunikation, das Marshaling, das Unmarshalling und die Erzwingung von Fristen. Mithilfe von Fristen kann Ihre Anwendung angeben, wie lange sie auf den Abschluss einer Anfrage warten soll, bevor die Anfrage mit dem Fehler für das Zeitlimit überschritten wird.

Im Leitfaden zur Konfiguration einer Zeitüberschreitung sehen Sie, wie Sie in den unterstützten Spanner-Clientbibliotheken Fristen (oder Zeitlimits) festlegen können. Die Spanner-Clientbibliotheken verwenden die Standardeinstellungen für Zeitüberschreitungen und Wiederholungsrichtlinien, 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

Eine Spanner-Instanz muss entsprechend für Ihre spezifischen Arbeitslasten konfiguriert werden, um Probleme mit der API für den Datenzugriff 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 sich erheblich erhöhen, wenn die CPU-Auslastung den empfohlenen fehlerfreien Schwellenwert überschreitet. Sie können die Spanner-CPU-Auslastung in der Monitoring-Konsole in der Google Cloud Console prüfen. Sie können auch Benachrichtigungen basierend auf der CPU-Auslastung der Instanz erstellen.

Lösung

Schritte zum Verringern 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 gesendet werden: von der Clientbibliothek zum Google Front End (GFE), vom GFE zum Spanner API-Front-End und schließlich vom Spanner API-Front-End zur Spanner-Datenbank. Wenn in einer dieser Phasen Netzwerkprobleme auftreten, werden möglicherweise Fehler aufgrund von Zeitüberschreitungen angezeigt.

Es ist möglich, die Latenz in jeder Phase zu erfassen (siehe Latenzleitfaden). Weitere Informationen zum Diagnoseleitfaden 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 Behebung von Latenzproblemen die Ursache der Latenz ermitteln und nachvollziehen, warum sie auftritt.

Probleme mit der Data API

Bestimmte nicht optimale Nutzungsmuster der Data API können zu Fehlern führen, die die Frist überschreiten. Dieser Abschnitt enthält Richtlinien zum Prüfen dieser nicht optimalen Nutzungsmuster.

Auf teure Abfragen prüfen

Wenn Sie teure Abfragen ausführen möchten, die nicht innerhalb der konfigurierten Zeitüberschreitung in den Clientbibliotheken ausgeführt werden, kann dies zu einem Fehler für das Zeitlimit führen. Beispiele für teure Abfragen sind unter anderem vollständige Scans einer großen Tabelle, Cross-Join ü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 Tabelle für Abfragestatistiken und der Tabelle für Transaktionsstatistiken prüfen. Diese Tabellen enthalten Informationen zu langsam ausgeführten Abfragen und Transaktionen, z. B. die durchschnittliche Anzahl der gelesenen Zeilen, die durchschnittliche Menge gelesener 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 finden Sie im Leitfaden zu Best Practices für SQL-Abfragen. Sie können auch die Daten verwenden, die Sie mit den oben genannten Statistiktabellen und den Ausführungsplänen abgerufen 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 und möglicherweise die Fristüberschreitungen zu beheben.

Auf Sperrkonflikte prüfen

Spanner-Transaktionen müssen Sperren erhalten, damit ein Commit durchgeführt werden kann. Anwendungen, die mit einem hohen Durchsatz ausgeführt werden, können dazu führen, dass Transaktionen um dieselben Ressourcen konkurrieren. Dies führt zu einer erhöhten Wartezeit, bis die Sperren wirksam werden, und beeinträchtigt die Gesamtleistung. Das kann zu Fristen für Lese- oder Schreibanfragen führen.

Die Ursache für Lese-/Schreibtransaktionen mit hoher Latenz finden Sie in der Tabelle der Sperrstatistiken und im folgenden Blogpost. In der Tabelle mit den Sperrstatistiken finden Sie die Zeilenschlüssel mit den höchsten Wartezeiten.

In dieser Anleitung zur Fehlerbehebung bei Sperrkonflikten wird erläutert, wie Sie die Transaktionen finden, die auf die Spalten zugreifen, die im Sperrkonflikt enthalten sind. Außerdem erfahren Sie im Leitfaden zur Fehlerbehebung bei Transaktions-Tags, welche Transaktionen an einem Sperrkonflikt beteiligt sind.

Lösung

Mit diesen Best Practices kannst du Sperrkonflikte vermeiden. Verwenden Sie außerdem schreibgeschützte Transaktionen für einfache Leseanwendungsfälle, um Sperrkonflikte mit den Schreibvorgängen zu vermeiden. Die Verwendung von Lese-Schreib-Transaktionen sollte für Schreibvorgänge oder gemischte Lese-/Schreib-Workflows reserviert werden. Wenn Sie diese Schritte ausführen, sollten Sie die Gesamtlatenz Ihrer Transaktionsausführungszeit verringern und die Fristen für überschrittene Fehler reduzieren.

Auf 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. Suboptimale 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. Unabhängig von den spezifischen Angaben des Schemas sollten die Best Practices für das Schemadesign und die Best Practices für SQL-SQL beachtet werden. Mit diesen Leitfäden können Sie die häufigsten Probleme beim Schemadesign vermeiden. Einige andere Ursachen für eine schlechte Leistung sind Ihrer Auswahl von Primärschlüsseln, dem Tabellenlayout (siehe verschränkte Tabellen für einen schnelleren Zugriff), dem Schemadesign (siehe Optimierungsschema für die Leistung) und der Leistung des Knotens zu entnehmen, der in Ihrer Spanner-Instanz konfiguriert ist (siehe regionale Limits oder multiregionale Limits).

Auf Hotspots prüfen

Da Spanner eine verteilte Datenbank ist, muss im Schemadesign Hotspots vermieden werden. Wenn Sie beispielsweise kontinuierlich Spalten erhöhen, 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. Außerdem können Sie mit Key Visualizer Leistungsprobleme aufgrund von Hotspots beheben.

Lösung

Eine Lösung für dieses Problem finden Sie im Abschnitt Auf nicht optimierte Schemas prüfen. Passen Sie Ihr Datenbankschema an und verwenden Sie verschränkte Indexe, um Indexe zu vermeiden, die zu Hotspots führen können. Wenn das Problem durch diese Schritte nicht behoben wird, lesen Sie den Leitfaden zum Auswählen eines Primärschlüssels, um Hotspots zu verhindern. Schließlich vermeiden Sie suboptimale Trafficmuster wie Lesevorgänge im großen Bereich, 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 anzupassen, damit sie für Ihren spezifischen 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 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 auf das Ergebnis warten möchte. Sie können mit längeren konfigurierten Zeitlimits experimentieren, aber niemals ein Zeitlimit festlegen, das kürzer ist als die tatsächliche Wartezeit der Anwendung, 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. 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. Dadurch wird sichergestellt, dass der Server die Anfrage abschließen kann, bevor der Client es noch einmal versucht oder fehlschlägt.

Lösung

Wenn Sie die Google Spanner-Clientbibliothek für den Zugriff auf die Admin API verwenden, muss die Clientbibliothek auf dem neuesten Stand sein und die neueste Version verwenden. Wenn Sie direkt über eine von Ihnen erstellte Clientbibliothek auf die Spanner API zugreifen, achten Sie darauf, dass Sie für Ihre Instanz- und Datenbankadministratoranfragen keine aggressiveren Fristeinstellungen als die Standardeinstellungen (60 Minuten) verwenden.

Probleme mit der Google Cloud Console

Abfragen, die von der Abfrageseite der Google Cloud Console stammen, 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 ü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 Leitfaden zu Best Practices für SQL-Abfragen umschreiben.

Probleme mit Dataflow

In Apache Beam beträgt die Standard-Zeitüberschreitungskonfiguration zwei 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 mehr Zeit. Wenn die Arbeitselemente jedoch zu groß sind, kann es trotzdem zu einem Fehler bei Zeitüberschreitung und überschrittenem Zeitlimit kommen. Derzeit kann die Commit-Zeitüberschreitungskonfiguration von 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, prüfen Sie die Abfragestatistiktabelle, um herauszufinden, welche Abfrage eine große Anzahl von Zeilen gescannt hat. Ändern Sie dann die Abfragen, um die Ausführungszeit zu reduzieren.

Ein weiteres Beispiel für einen Fehler beim Überschreiten der Dataflow-Zeit 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 ist aufgetreten, weil die Aufgaben zu groß sind. Im obigen Beispiel könnten 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 in Ihrer Leseumgebung zu optimieren, z. B. maxPartitions und partitionSizeBytes. Weitere Informationen finden Sie unter PartitionOptions, um die Größe der Arbeitselemente zu reduzieren. Ein Beispiel dafür finden Sie in dieser Dataflow-Vorlage.

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

Wenn nach Ausführung der oben genannten Schritte zur Fehlerbehebung immer noch ein Zeitüberschreitungsfehler angezeigt wird, können Sie anhand 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 eines der folgenden Szenarien auftritt:

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

Weitere Informationen finden Sie in den folgenden Ressourcen zur Fehlerbehebung: