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.

Ursache ermitteln

  1. Prüfen Sie die Messwerte Datenaktualität und Backlog-Bytes.

    • Wenn beide Messwerte monoton steigen, bedeutet das, dass die Pipeline nicht weiterläuft.
    • Wenn die Datenaktualität zunimmt, die Anzahl der Backlog-Bytes aber normal bleibt, bedeutet das, dass ein oder mehrere Arbeitselemente in der Pipeline hängen bleiben.

    Suchen Sie nach den Phasen, in denen diese Messwerte steigen, um Phasen mit Problemen und die in dieser Phase ausgeführten Vorgänge zu ermitteln.

  2. Sehen Sie sich das Diagramm zur parallelen Verarbeitung an, um festzustellen, ob eine Phase aufgrund von zu viel oder zu wenig Parallelität hängen bleibt. Weitere Informationen

  3. Prüfen Sie die Job-Logs auf Probleme wie Kontingentbeschränkungen, Probleme mit nicht verfügbaren Artikeln oder aufgebrauchte IP-Adressen.

  4. Prüfen Sie die Worker-Logs auf Warnungen und Fehler.

    • Wenn Worker-Logs Fehler enthalten, sehen Sie sich den Stacktrace an. Prüfen Sie, ob der Fehler durch einen Fehler in Ihrem Code verursacht wird.
    • Suchen Sie nach Dataflow-Fehlern. Weitere Informationen finden Sie unter Fehlerbehebung bei Dataflow-Fehlern.
    • Suchen Sie nach Fehlern, die darauf hinweisen, dass das Limit für den Job überschritten wurde, z. B. die maximale Größe von Pub/Sub-Nachrichten.
    • Suchen Sie nach Fehlern aufgrund von fehlendem Arbeitsspeicher, die zu einer blockierten Pipeline führen können. Wenn Sie Fehler aufgrund von Speichermangel sehen, folgen Sie der Anleitung unter Fehlerbehebung bei Dataflow-Fehlern aufgrund von Speichermangel.
    • Wenn Sie einen langsamen oder hängenden Schritt ermitteln möchten, suchen Sie in den Worker-Logs nach Operation ongoing-Meldungen. Sehen Sie sich den Stacktrace an, um zu sehen, wo der Schritt Zeit benötigt. Weitere Informationen finden Sie unter Verarbeitung hängt oder Vorgang läuft.

  5. Wenn ein Arbeitselement auf einem bestimmten Worker hängen bleibt, starten Sie die entsprechende Worker-VM neu.

  6. Wenn Sie Streaming Engine nicht verwenden, prüfen Sie die Shuffler-Logs auf Warnungen und Fehler. Wenn Sie einen RPC-Zeitüberschreitungsfehler auf Port 12345 oder 12346 sehen, fehlt in Ihrem Job möglicherweise eine Firewallregel. Weitere Informationen finden Sie unter Firewallregeln für Dataflow.

  7. Auf „heiße“ Schlüssel prüfen:

  8. Wenn Runner v2 aktiviert ist, prüfen Sie die Harness-Logs auf Fehler. Weitere Informationen finden Sie unter Fehlerbehebung für Runner v2.

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.

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:

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.

Probleme mit der Parallelität beheben

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. Kafka-Partitionen.
  • Der Schlüssel wird explizit durch Aggregationslogik in der Pipeline definiert, z. B. GroupByKey.

In Dataflow sind Worker-Threads für die Verarbeitung von Arbeitsbündeln (Nachrichten) für einen Schlüssel zuständig. Die Anzahl der verfügbaren Threads zum Verarbeiten der Schlüssel des Jobs ist gleich num_of_workers * threads_per_worker. Die Anzahl der Threads pro Worker wird anhand des SDK (Java, Python oder Go) und des Jobtyps (Batch oder Streaming) bestimmt.

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.

Wenn in der Pipeline eine sehr große Anzahl von Schlüsseln für eine bestimmte Phase verwendet wird, kann dies den Durchsatz der Phase einschränken und zu einem Rückstand in den Upstream-Phasen führen, da pro Schlüssel ein gewisser Overhead anfällt. Der Mehraufwand kann die Kommunikation des Backends mit Workern, externe RPCs an ein Ziel wie BigQuery und andere Verarbeitung umfassen. Wenn die Verarbeitung eines Schlüssels mit einer Nachricht beispielsweise 100 ms dauert, kann die Verarbeitung von 1.000 Nachrichten in diesem Schlüsselbündel auch etwa 100 ms dauern.

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 auf dem Tab Autoscaling, 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.

Phasen mit hoher Parallelität identifizieren

Eine Kombination aus niedriger Systemlatenz, zunehmender Datenaktualität, wachsendem Rückstand und unterausgelasteten Worker-CPUs deutet darauf hin, dass die Pipeline aufgrund einer großen Anzahl von Schlüsseln gedrosselt wird. Sehen Sie sich das Diagramm zur Parallelverarbeitung an, um Phasen mit einer großen Anzahl von Schlüsseln zu identifizieren.

Transformationen wie Reshuffle können Millionen von Schlüsseln generieren, wenn Sie withNumBuckets nicht explizit angeben. Eine große Anzahl von Schlüsseln kann zur Erstellung zahlreicher kleinerer Arbeitsbündel führen, für deren Verarbeitung jeweils ein eigener Worker-Thread erforderlich ist. Da die verfügbaren Worker-Threads begrenzt sind, kann es zu einem erheblichen Rückstand bei der Verarbeitung von Schlüsseln kommen, was zu Verzögerungen führt, da sie auf Ressourcen warten. Daher werden die Worker-Threads nicht effizient genutzt.

Wir empfehlen, die Anzahl der Schlüssel zu begrenzen, indem Sie die Option withNumBuckets in der Transformation Reshuffle festlegen. Der Wert darf die Gesamtzahl der Threads aller Worker nicht überschreiten. Das Targeting auf (threads_per_worker * max_workers)-Schlüssel in der Pipeline ist möglicherweise nicht optimal. Manchmal sind weniger Schlüssel und größere Bundles möglich. Sie werden von Dataflow effizienter verarbeitet, da weniger Worker verwendet werden. Eine geringere Anzahl von Schlüsseln führt zu größeren Arbeitsbündeln, wodurch die Worker-Threads effizient genutzt und der Durchsatz der Phase erhöht wird.

Wenn es in der Pipeline mehrere Reshuffle-Schritte gibt, teilen Sie die Gesamtzahl der Threads durch die Anzahl der Reshuffle-Schritte, um withNumBuckets zu berechnen.

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.

Prüfen Sie mit dem folgenden Logfilter, ob Hotkeys verwendet werden:

  resource.type="dataflow_step"
  resource.labels.job_id=JOB_ID
  jsonPayload.line:"hot_key_logger"

Ersetzen Sie JOB_ID durch die ID Ihrer Jobs.

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 in der Klasse Combine.PerKey im Java SDK oder im 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:

  1. Rufen Sie die Google Cloud Console auf.
  2. Klicken Sie im Navigationsbereich auf APIs & Dienste.
  3. Klicken Sie im Menü auf Bibliothek.
  4. Geben Sie in das Suchfeld Pub/Sub ein.
  5. Klicken Sie auf Cloud Pub/Sub API.
  6. Klicken Sie auf Verwalten.
  7. 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:

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

    Zu Monitoring

  2. Wählen Sie im Navigationsbereich Metrics Explorer aus.

  3. 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.

Ursache ermitteln

  1. Prüfen Sie, ob beim Starten des Workers Probleme auftreten. Weitere Informationen finden Sie unter Fehler beim Synchronisieren des Pods.

    Sehen Sie im job-message-Log nach dem folgenden Logeintrag, um zu prüfen, ob der Job mit der Verarbeitung von Daten begonnen hat:

    All workers have finished the startup processes and began to receive work requests

  2. Wenn Sie die Leistung verschiedener Jobs vergleichen möchten, müssen das Volumen der Eingabedaten, die Worker-Konfiguration, das Autoscaling-Verhalten und die Dataflow Shuffle-Einstellungen identisch sein.

  3. Prüfen Sie die job-message-Logs auf Probleme wie Kontingentbeschränkungen, Probleme mit nicht verfügbaren Artikeln oder aufgebrauchte IP-Adressen.

  4. Vergleichen Sie auf dem Tab Ausführungsdetails den Phasenfortschritt, um Phasen zu ermitteln, die länger gedauert haben.

  5. Suchen Sie nach verbliebenen Fäden. Weitere Informationen finden Sie unter Fehlerbehebung bei Nachzüglern in Batchjobs.

  6. Prüfen Sie die Messwerte für Durchsatz, CPU und Arbeitsspeicherauslastung.

  7. Prüfen Sie die Worker-Logs auf Warnungen und Fehler.

  8. Auf „heiße“ Schlüssel prüfen:

  9. Wenn Sie Dataflow Shuffle nicht verwenden, prüfen Sie die Shuffler-Logs auf Warnungen und Fehler während des Shuffle-Vorgangs. Wenn Sie einen RPC-Zeitüberschreitungsfehler auf Port 12345 oder 12346 sehen, fehlt in Ihrem Job möglicherweise eine Firewallregel. Weitere Informationen finden Sie unter Firewallregeln für Dataflow.

  10. Wenn Runner v2 aktiviert ist, prüfen Sie die Harness-Logs auf Fehler. Weitere Informationen finden Sie unter Fehlerbehebung für Runner v2.

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 Batchjobs.

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:

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.