Fehler aufgrund von überschrittenen Spanner-Zeitlimits beheben

Auf dieser Seite erhalten Sie einen Überblick über Fehler aufgrund von Überschreitungen des Spanner-Zeitlimits: worum es sich handelt, warum sie auftreten und wie sie behoben werden können.

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.

Ein Fehler beim Überschreiten einer Frist kann aus verschiedenen Gründen wie überlastete Spanner-Instanzen, nicht optimierte Schemas oder nicht optimierte Abfragen auftreten. Auf dieser Seite werden häufige Szenarien beschrieben, in denen Fehler aufgrund einer Frist überschritten werden. Außerdem erhalten Sie eine Anleitung zur Untersuchung und Behebung dieser Probleme.

Frist und Wiederholungsphilosophie von Spanner

Die Frist- und Wiederholungsphilosophie von Spanner unterscheidet sich von vielen anderen Systemen. In Spanner sollten Sie ein Zeitlimit als Zeitlimit angeben, in dem eine Antwort maximal nützlich ist. Es empfiehlt sich nicht, eine künstlich kurze Frist festzulegen, um denselben Vorgang sofort noch einmal zu wiederholen, da dies zu Situationen führt, in denen Vorgänge nie abgeschlossen werden. In diesem Kontext werden die folgenden Strategien und Vorgänge nicht empfohlen. Sie sind kontraproduktiv und verhindern das interne Wiederholungsverhalten von Spanner:

  • Eine zu kurze Frist festlegen Das bedeutet, dass der Vorgang nicht resistent gegenüber gelegentlichen Extremwert-Latenzerhöhungen ist und nicht vor einer Zeitüberschreitung abgeschlossen werden kann. Legen Sie stattdessen eine Frist fest, die die maximale Zeitdauer darstellt, in der eine Antwort nützlich ist.

  • Sie legen eine zu lange Frist fest und brechen den Vorgang vor Ablauf der Frist ab. Dies führt zu Wiederholungen und verschwendetem Arbeitsaufwand bei jedem Versuch. Dies kann insgesamt zu einer erheblichen zusätzlichen Belastung Ihrer Instanz führen.

Was ist ein Fehler aufgrund einer Fristüberschreitung?

Wenn Sie eine der Spanner-Clientbibliotheken verwenden, übernimmt die zugrunde liegende gRPC-Ebene die Kommunikation, das Marshalling, das Unmarshalling und die Erzwingung von Fristen. Anhand von Fristen kann Ihre Anwendung angeben, wie lange sie auf den Abschluss einer Anfrage warten muss, bevor die Anfrage mit dem Fehler „Frist überschritten“ beendet wird.

In der Konfigurationsanleitung für Zeitüberschreitungen wird gezeigt, wie Sie in jeder der unterstützten Spanner-Clientbibliotheken Fristen (oder Zeitlimits) angeben 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-Zeitlimits finden Sie unter gRPC und Fristen.

Häufige Fehler aufgrund von überschrittenen Fristen untersuchen und beheben

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

Probleme mit der Datenzugriffs-API

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

CPU-Auslastung der Spanner-Instanz prüfen

Die Anfragelatenz kann erheblich zunehmen, wenn die CPU-Auslastung den empfohlenen Schwellenwert für Intaktheit überschreitet. Sie können die Spanner-CPU-Auslastung in der Monitoring-Konsole der Google Cloud Console prüfen. Außerdem haben Sie die Möglichkeit, Benachrichtigungen basierend auf der CPU-Auslastung der Instanz zu erstellen.

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, 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 aufgrund von Zeitüberschreitungen angezeigt.

Es ist möglich, die Latenz in jeder Phase zu erfassen. Weitere Informationen finden Sie unter Latenzpunkte in einer Spanner-Anfrage. Informationen dazu, wo die Latenz in Spanner auftritt, finden Sie unter Latenz in Spanner ermitteln.

Lösung

Sobald Sie die Latenzaufschlüsselung erhalten haben, können Sie die Latenz anhand von Messwerten diagnostizieren, die Ursache des Problems ermitteln und Lösungen finden.

Probleme mit Daten-API

Bestimmte nicht optimale Nutzungsmuster der Data API von Spanner können zu Fehlern aufgrund von Zeitüberschreitungen führen. Dieser Abschnitt enthält Richtlinien zur Überprüfung auf solche nicht optimalen Nutzungsmuster.

Auf teure Abfragen prüfen

Wenn Sie versuchen, teure Abfragen auszuführen, die nicht innerhalb der konfigurierten Zeitüberschreitung in den Clientbibliotheken ausgeführt werden, kann dies zu einem Fehler durch Überschreiten der Frist führen. Einige Beispiele für teure 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 (auch ein vollständiger Tabellenscan).

Sie können teure Abfragen mit der Tabelle mit der Abfragestatistik und der Tabelle mit der Transaktionsstatistik prüfen. Diese Tabellen enthalten Informationen zu langsam ausgeführten Abfragen und Transaktionen, z. B. die durchschnittliche Anzahl gelesener Zeilen, die durchschnittlich gelesene Byte, die durchschnittliche Anzahl der gescannten Zeilen und mehr. Darüber hinaus können Sie Abfrageausführungspläne generieren, um die Ausführung Ihrer Abfragen weiter zu untersuchen.

Lösung

Informationen zum Optimieren Ihrer Abfragen finden Sie im Leitfaden mit Best Practices für SQL-Abfragen. Sie können auch die Daten aus den zuvor erwähnten Statistiktabellen und Ausführungspläne verwenden, 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 reduzieren, was möglicherweise dazu beitragen kann, Fehler aufgrund von Fristüberschreitungen zu vermeiden.

Auf Konflikt bei einer Sperre prüfen

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

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

In dieser Anleitung zur Fehlerbehebung bei Sperrkonflikten wird erläutert, wie Sie die Transaktionen ermitteln, die auf die am Sperrkonflikt beteiligten Spalten zugreifen. Außerdem können Sie in der Anleitung zur Fehlerbehebung mit Transaktions-Tags herausfinden, welche Transaktionen von einem Sperrkonflikt betroffen sind.

Lösung

Wenden Sie diese Best Practices an, um Konflikte durch Sperren 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-/Schreibtransaktionen sollte für Schreibvorgänge oder gemischte Lese-/Schreib-Workflows reserviert sein. Mit diesen Schritten sollten Sie die Gesamtlatenz der Ausführungszeit der Transaktion verbessern und Fehler aufgrund von Zeitüberschreitungen reduzieren.

Auf nicht optimierte Schemas prüfen

Bevor Sie ein optimales Datenbankschema für Ihre Spanner-Datenbank entwerfen, sollten Sie sich überlegen, welche Arten von Abfragen in der Datenbank ausgeführt werden sollen. Suboptimale Schemas können beim Ausführen 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 Best Practices für das Schemadesign und die Best Practices für SQL sollten unabhängig von den Schemadetails eingehalten werden. Durch Befolgen dieser Anleitungen vermeiden Sie die häufigsten Probleme beim Schemadesign. Einige andere Ursachen für eine schlechte Leistung sind auf Ihre Auswahl der Primärschlüssel, das Tabellenlayout (siehe Verschränkte Tabellen für einen schnelleren Zugriff verwenden), das Schemadesign (siehe Schema für Leistung optimieren) und die Leistung des in Ihrer Spanner-Instanz konfigurierten Knotens (siehe Leistungsübersicht von Spanner) zurückzuführen.

Auf Hotspots prüfen

Da es sich bei Spanner um eine verteilte Datenbank handelt, muss im Schemadesign die Vermeidung von Hotspots berücksichtigt werden. Wenn Sie beispielsweise kontinuierlich ansteigende 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. Außerdem können Sie mit Key Visualizer Leistungsprobleme aufgrund von Hotspots beheben.

Lösung

Sehen Sie sich als ersten Schritt zur Lösung dieses Problems die Lösungen im vorherigen Abschnitt Nach nicht optimierten Schemas suchen an. Gestalten Sie Ihr Datenbankschema neu und verwenden Sie verschränkte Indexe, um Indexe zu vermeiden, die zu Hotspots führen können. Wenn das Problem durch die folgenden Schritte nicht behoben wird, lesen Sie die Anleitung zum Auswählen eines Primärschlüssels zur Vermeidung von Hotspots. Vermeiden Sie außerdem suboptimale Trafficmuster wie Lesevorgänge mit großer Reichweite, die eine lastbasierte Aufteilung verhindern könnten.

Auf falsch konfigurierte Zeitüberschreitungen prüfen

Die Clientbibliotheken bieten angemessene Standardeinstellungen für Zeitü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 für Ihre Abfragen zu beobachten und die Fristen an Ihren 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 Anleitung zu benutzerdefinierten Zeitüberschreitungen und Wiederholungen). Es wird jedoch nicht empfohlen, höhere Zeitüberschreitungen als die Standardzeitlimits zu verwenden. Wenn Sie das Zeitlimit ändern möchten, legen Sie dafür die tatsächliche Zeit fest, die die Anwendung bereit ist, auf das Ergebnis zu warten. Sie können mit längeren konfigurierten Zeitüberschreitungen experimentieren, aber niemals ein Zeitlimit festlegen, das kürzer als die tatsächliche Zeit ist, die die Anwendung wartet, da dies dazu führen würde, dass der Vorgang häufiger wiederholt wird.

Probleme mit der Admin API

Im Vergleich zu Data API-Anfragen sind Admin API-Anfragen teure Vorgänge. Bei Administratoranfragen wie CreateInstance, CreateDatabase oder CreateBackups kann es viele Sekunden dauern, bis eine Antwort zurückgegeben wird. Spanner-Clientbibliotheken legen Fristen von 60 Minuten für Anfragen von Instanz- und Datenbankadministratoren fest. So soll sichergestellt werden, dass der Server die Möglichkeit hat, die Anfrage abzuschließen, bevor der Client es noch einmal versucht oder fehlschlägt.

Lösung

Wenn Sie mit der Spanner-Clientbibliothek von Google auf die Administrator-API zugreifen, muss die Clientbibliothek aktualisiert sein und die neueste Version verwenden. Wenn Sie direkt über eine von Ihnen erstellte Clientbibliothek auf die Spanner API zugreifen, dürfen für die Anfragen des Instanz- und Datenbankadministrators keine strengeren Fristeneinstellungen als die Standardeinstellungen (60 Minuten) festgelegt sein.

Probleme mit der Google Cloud Console

Abfragen, die von der Spanner Studio-Seite in 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 „Zeitüberschreitung der Google Cloud Console-Zeitüberschreitung“

Das Back-End bricht die fehlgeschlagene Abfrage ab und die Transaktion kann bei Bedarf zurückgesetzt werden.

Lösung

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

Dataflow-Probleme

In Apache Beam beträgt die Standardkonfiguration für Zeitüberschreitungen für Lesevorgänge zwei Stunden und für Commit-Vorgänge 15 Sekunden. Diese Konfigurationen ermöglichen im Vergleich zu Zeitüberschreitungen der eigenständigen Clientbibliothek längere Vorgänge. Es ist jedoch möglich, dass Sie einen Fehler wegen Zeitüberschreitung und überschrittener Frist erhalten, wenn die Arbeitselemente zu groß sind. Bei Bedarf können Sie die Konfiguration für das Commit-Zeitlimit von Apache Beam anpassen.

Lösung

Wenn in den Schritten ReadFromSpanner / Execute query / Read from Spanner / Read from Partitions ein Fehler beim Überschreiten einer Frist auftritt, können Sie in der Abfragestatistiktabelle ermitteln, welche Abfrage eine große Anzahl von Zeilen gescannt hat. Ändern Sie dann diese Abfragen, um die Ausführungszeit zu reduzieren.

Die folgende Ausnahmemeldung zeigt ein weiteres Beispiel für einen Dataflow-Zeitüberschreitungsfehler:

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 darauf zurückzuführen, dass die Arbeitselemente zu groß sind. Im vorherigen Beispiel könnten die folgenden beiden Empfehlungen hilfreich sein. Sie können zuerst versuchen, den Shuffle-Dienst zu aktivieren, falls er noch nicht aktiviert ist. Zweitens können Sie versuchen, die Konfigurationen des Lesevorgangs Ihrer Datenbank zu optimieren, z. B. maxPartitions und partitionSizeBytes. Unter PartitionOptions erfahren Sie, wie Sie die Größe der Arbeitsaufgabe reduzieren können. Ein Beispiel dafür finden Sie in dieser Dataflow-Vorlage.

Zusätzliche Frist hat Ressourcen zur Fehlerbehebung überschritten

Wenn nach Abschluss der Schritte zur Fehlerbehebung weiterhin der Fehler DEADLINE_EXCEEDED angezeigt wird, öffnen Sie eine Supportanfrage, wenn Folgendes zutrifft:

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

Sie können auch die folgenden Ressourcen zur Fehlerbehebung verwenden: