Fehlerbehebung bei langsamen oder hängenden Jobs

Auf dieser Seite wird erläutert, wie Sie häufige Ursachen von langsamen oder hängenden Dataflow-Streaming- und -Batchjobs beheben können.

Streaming

Wenn Sie die folgenden Symptome bemerken, wird Ihr Dataflow-Streamingjob möglicherweise langsam ausgeführt oder ist hängen geblieben:

Die Pipeline liest keine Daten aus der Quelle. Pub/Sub hat beispielsweise einen wachsenden Rückstand.
Die Pipeline schreibt keine Daten in die Senke.
Der Datenaktualitätsmesswert nimmt zu.
Der Systemlatenzmesswert nimmt zu.

Verwenden Sie die Informationen in den folgenden Abschnitten, um das Problem zu identifizieren und zu diagnostizieren.

Wiederholte Fehler untersuchen

Bei einem Streamingjob werden bei einigen Fehlern ohne Begrenzung neue Versuche unternommen. Diese Wiederholungen verhindern den Fortschritt der Pipeline. Prüfen Sie die Worker-Logs auf Ausnahmen, um wiederholte Fehler zu identifizieren.

Wenn es sich um eine Ausnahme im Nutzercode handelt, beheben Sie das Problem im Code oder in den Daten.
Implementieren Sie eine Dead-Letter-Warteschlange, um unerwartete Fehler zu vermeiden. Eine Beispielimplementierung finden Sie in der Apache Beam-Dokumentation unter BigQuery-Muster.
Wenn eine Ausnahme in Bezug auf ungenügenden Arbeitsspeicher auftritt, lesen Sie Fehlerbehebung bei Dataflow-Fehlern aufgrund von ungenügendem Arbeitsspeicher.
Informationen zu anderen Ausnahmen finden Sie unter Fehlerbehebung bei Dataflow-Fehlern.

Fehlerhafte Worker ermitteln

Wenn die Worker, die den Streamingjob verarbeiten, fehlerhaft sind, ist der Job möglicherweise langsam oder scheint festzuhängen. So identifizieren Sie fehlerhafte Worker:

Prüfen Sie die Arbeitsspeichersituation mithilfe der Messwerte zur Arbeitsspeicherauslastung und suchen Sie in den Worker-Logs nach Arbeitsspeicherfehlern. Weitere Informationen finden Sie unter Fehlerbehebung bei Dataflow-Fehlern aufgrund von ungenügendem Arbeitsspeicher.
Wenn Sie Streaming Engine verwenden, nutzen Sie die Persistenzmesswerte, um Engpässe bei den Ein-/Ausgabevorgängen des Laufwerks (IOPS) zu identifizieren.
Prüfen Sie die Worker-Logs auf andere Fehler. Weitere Informationen finden Sie unter Mit Pipelinelogs arbeiten und Dataflow-Fehler beheben.

Nachzügler identifizieren

Ein Nachzügler ist ein Arbeitselement, das relativ zu anderen Arbeitselementen in der Phase langsam ist. Informationen zum Identifizieren und Korrigieren von Nachzüglern finden Sie unter Fehlerbehebung bei Nachzüglern in Streamingjobs.

Fehlerbehebung bei unzureichender Parallelität

Aus Gründen der Skalierbarkeit und Effizienz führt Dataflow die Phasen Ihrer Pipeline parallel auf mehreren Workern aus. Die kleinste Einheit der parallelen Verarbeitung in Dataflow ist ein Schlüssel. Eingehende Nachrichten für jede zusammengeführte Phase sind einem Schlüssel zugeordnet. Der Schlüssel wird auf eine der folgenden Arten definiert:

Der Schlüssel wird implizit durch die Attribute der Quelle definiert, z. B. Pub/Sub-Partitionen.
Der Schlüssel wird explizit durch Aggregationslogik in der Pipeline definiert, z. B. GroupByKey.

Wenn die Pipeline für eine bestimmte Phase nicht genügend Schlüssel hat, begrenzt das die parallele Verarbeitung. Diese Phase kann zum Engpass werden.

Phasen mit niedriger Parallelität identifizieren

Prüfen Sie die CPU-Auslastungsmesswerte, um festzustellen, ob die Langsamkeit der Pipeline durch eine niedrige Parallelität verursacht wird. Wenn die CPU-Auslastung niedrig, aber gleichmäßig auf die Worker verteilt ist, hat Ihr Job möglicherweise eine unzureichende Parallelität. Wenn Ihr Job Streaming Engine verwendet, sehen Sie sich auf dem Tab Jobmesswerte die Parallelitätsmesswerte an, um festzustellen, ob eine Phase eine niedrige Parallelität hat. So beheben Sie das Problem:

Prüfen Sie in der Google Cloud Console auf der Seite Jobinformationen den Tab Autoscaling, um zu sehen, ob Probleme beim Hochskalieren vorliegen. Wenn das Problem beim Autoscaling liegt, finden Sie weitere Informationen unter Fehlerbehebung beim Dataflow-Autoscaling.
Mit der Jobgrafik können Sie die Schritte in der Phase prüfen. Wenn die Phase aus einer Quelle liest oder in eine Senke schreibt, lesen Sie die Dokumentation für den Dienst der Quelle oder Senke. Ermitteln Sie anhand der Dokumentation, ob dieser Dienst für ausreichende Skalierbarkeit konfiguriert ist.
- Weitere Informationen finden Sie unter den Eingabe- und Ausgabemesswerten von Dataflow.
- Wenn Sie Kafta verwenden, prüfen Sie die Anzahl der Kafka-Partitionen. Weitere Informationen finden Sie in der Dokumentation zu Apache Kafka.
- Wenn Sie eine BigQuery-Senke verwenden, aktivieren Sie die automatische Fragmentierung, um die Parallelität zu verbessern. Weitere Informationen finden Sie unter Dreifacher Dataflow-Durchsatz mit automatischer Fragmentierung für BigQuery.

Auf "heiße" Schlüssel prüfen

Wenn Aufgaben ungleichmäßig auf Worker verteilt sind und die Worker-Auslastung sehr ungleichmäßig ist, hat Ihre Pipeline möglicherweise einen "heißen" Schlüssel. Ein "heißer" Schlüssel ist ein Schlüssel, der im Vergleich zu anderen Schlüsseln viel mehr Elemente verarbeiten muss. Führen Sie einen oder mehrere der folgenden Schritte aus, um dieses Problem zu beheben:

Daten nochmal zur Verfügung stellen. Wenden Sie eine ParDo-Transformation an, um neue Schlüssel/Wert-Paare auszugeben. Weitere Informationen finden Sie auf der Java-ParDo-Transformationsseite oder auf der Python-ParDo-Transformationsseite in der Apache Beam-Dokumentation.
Verwenden Sie .withFanout in Combine-Transformationen. Weitere Informationen finden Sie bei der Klasse Combine.PerKey im Java SDK oder beim Vorgang with_hot_key_fanout im Python SDK
Wenn Sie eine Java-Pipeline haben, die unbegrenzte PCollections mit hohem Volumen verarbeitet, empfehlen wir Folgendes:
- Verwenden Sie Combine.Globally.withFanout anstelle von Combine.Globally.
- Verwenden Sie Combine.PerKey.withHotKeyFanout anstelle von Count.PerKey.

Auf unzureichendes Kontingent prüfen

Achten Sie darauf, dass Ihr Kontingent für die Quelle und die Senke ausreicht. Wenn Ihre Pipeline beispielsweise Eingaben aus Pub/Sub oder BigQuery liest, hat Ihr Google Cloud-Projekt möglicherweise nicht genügend Kontingent. Weitere Informationen zu Kontingentlimits für diese Dienste finden Sie unter Pub/Sub-Kontingente oder BigQuery-Kontingente.

Wenn der Job eine hohe Anzahl von Fehlern des Typs 429 (Rate Limit Exceeded) generiert, ist das Kontingent möglicherweise nicht ausreichend. Führen Sie die folgenden Schritte aus, um auf Fehler zu prüfen:

Öffnen Sie die Google Cloud Console.
Klicken Sie im Navigationsbereich auf APIs & Dienste.
Klicken Sie im Menü auf Bibliothek.
Geben Sie in das Suchfeld Pub/Sub ein.
Klicken Sie auf Cloud Pub/Sub API.
Klicken Sie auf Verwalten.
Suchen Sie im Diagramm Traffic nach Antwortcode nach (4xx)-Clientfehlercodes.

Sie können auch Metrics Explorer verwenden, um die Kontingentnutzung zu prüfen. Wenn Ihre Pipeline eine BigQuery-Quelle oder -Senke verwendet, verwenden Sie die BigQuery Storage API-Messwerte, um Kontingentprobleme zu beheben. So erstellen Sie beispielsweise ein Diagramm mit der Anzahl gleichzeitiger BigQuery-Verbindungen:

Wählen Sie in der Google Cloud Console Monitoring aus:

Zu Monitoring
Wählen Sie im Navigationsbereich Metrics Explorer aus.
Filtern Sie im Bereich Messwert auswählen für Messwert zu BigQuery-Projekt >Schreiben >Anzahl gleichzeitiger Verbindungen.

Eine Anleitung zum Aufrufen von Pub/Sub-Messwerten finden Sie unter Kontingentnutzung überwachen in "Pub/Sub in Cloud Monitoring überwachen". Eine Anleitung zum Aufrufen von BigQuery-Messwerten finden Sie unter Kontingentnutzung und -limits aufrufen in "Dashboards, Diagramme und Benachrichtigungen erstellen".

Batch

Wenn der Batchjob langsam läuft oder hängen geblieben ist, verwenden Sie den Tab Ausführungsdetails, um weitere Informationen zum Job zu erhalten und die Phase oder den Worker zu ermitteln, der den Engpass verursacht.

Nachzügler identifizieren

Langsame oder hängende Phasen identifizieren

Verwenden Sie die Ansicht Phasenfortschritt, um langsame oder hängende Phasen zu ermitteln. Längere Balken weisen darauf hin, dass die Phase länger dauert. Verwenden Sie diese Ansicht, um die langsamsten Phasen in Ihrer Pipeline zu ermitteln.

Nachdem Sie die Engpassphase gefunden haben, können Sie die folgenden Schritte ausführen:

Identifizieren Sie den verzögerten Worker in der Phase.
Wenn keine verzögerten Worker vorhanden sind, identifizieren Sie den langsamsten Schritt über den Bereich Phaseninformationen. Verwenden Sie diese Informationen, um Kandidaten für die Optimierung von Nutzercode zu identifizieren.
Verwenden Sie Dataflow-Monitoringmesswerte, um Engpässe bei der Parallelität zu finden.

Verzögerten Worker erkennen

Verwenden Sie die Ansicht Worker-Fortschritt, um einen verzögerten Worker für eine bestimmte Phase zu identifizieren. Diese Ansicht zeigt, ob alle Worker die Arbeit bis zum Ende der Phase verarbeiten oder ob ein einzelner Worker bei einer verzögerten Aufgabe festhängt. Wenn Sie einen verzögerten Worker finden, führen Sie die folgenden Schritte aus:

Sehen Sie sich die Logdateien für diesen Worker an. Weitere Informationen finden Sie unter Pipelinelogs überwachen und ansehen.
Sehen Sie sich die CPU-Auslastungsmesswerte und die Details zum Worker-Fortschritt für verzögerte Worker an. Wenn Sie eine ungewöhnlich hohe oder niedrige CPU-Auslastung feststellen, suchen Sie in den Logdateien für diesen Worker nach den folgenden Problemen:
- A hot key ... was detected
- Processing stuck ... Operation ongoing

Tools zur Fehlerbehebung

Wenn Sie eine langsame oder hängende Pipeline haben, können Sie mit den folgenden Tools versuchen, das Problem zu diagnostizieren.

Verwenden Sie Cloud Monitoring für Dataflow, um Vorfälle zu korrelieren und Engpässe zu identifizieren.
Verwenden Sie zum Überwachen der Pipelineleistung Cloud Profiler.
Einige Transformationen eignen sich besser für Pipelines mit hohem Volumen als andere. Lognachrichten können eine hängen gebliebene Nutzertransformation in Batch- oder Streamingpipelines identifizieren.
Weitere Informationen zu hängen gebliebenen Jobs finden Sie unter Dataflow-Jobmesswerte. Die folgende Liste enthält nützliche Messwerte:
- Der Messwert Rückstand in Byte (backlog_bytes) misst die Menge der nicht verarbeiteten Eingabe in Byte pro Phase. Verwenden Sie diesen Messwert, um einen zusammengeführten Schritt zu finden, der keinen Durchsatz hat. Der Messwert der Rückstandselemente (backlog_elements) misst die Anzahl der nicht verarbeiteten Eingabeelemente für eine Phase.
- Der Messwert Verarbeitungsparallelitätsschlüssel (processing_parallelism_keys) misst die Anzahl der parallelen Verarbeitungsschlüssel für eine bestimmte Phase der Pipeline in den letzten fünf Minuten. Verwenden Sie diesen Messwert, um Untersuchungen anzustellen:
  - Sie können das Problem auf bestimmte Phasen eingrenzen und Warnungen zu „heißen“ Schlüsseln wie A hot key ... was detected bestätigen.
  - Suchen Sie nach Durchsatzengpässen aufgrund unzureichender Parallelität. Diese Engpässe können zu langsamen oder hängenden Pipelines führen.
- Der Messwert Systemverzögerung (system_lag) und der Messwert für die verzögerte Systemverzögerung pro Phase (per_stage_system_lag) messen die maximale Zeitdauer, für die ein Datenelement verarbeitet wurde oder auf die Verarbeitung gewartet hat. Verwenden Sie diese Messwerte, um ineffiziente Phasen und Engpässe aus Datenquellen zu ermitteln.

Weitere Messwerte, die nicht in der Dataflow-Monitoring-Weboberfläche enthalten sind, finden Sie in der vollständigen Liste der Dataflow-Messwerte unter Google Cloud-Messwerte.