Ein Engpass tritt auf, wenn ein Schritt, eine Phase oder ein Worker den gesamten Job verlangsamt. Engpässe können zu inaktiven Workern und erhöhter Latenz führen.
Wenn Dataflow einen Engpass erkennt, wird in der Jobgrafik eine Warnung angezeigt. Im Bereich Schrittinformationen werden die Art des Engpasses und die Ursache aufgeführt, sofern bekannt. Dataflow exportiert auch Informationen zur Engpasserkennung in einen Stackdriver-Messwert, der die Daten als Zeitreihe darstellt. So können Sie Engpässe im Zeitverlauf oder in der Vergangenheit ansehen.
Engpässe verstehen
Wenn Dataflow eine Streamingpipeline ausführt, besteht der Job aus einer
Reihe von Komponenten, z. B.
Streaming-Shuffles,
Verarbeitungsthreads für benutzerdefinierte Funktionen (DoFn) und Checkpointing des nichtflüchtigen Zustands
. Um den Datenfluss zu erleichtern, verwendet Dataflow Warteschlangen, um diese Komponenten zu verbinden. Daten werden von der Upstream- zur Downstream-Komponente übertragen.
In vielen Pipelines wird die Gesamtdurchsatzkapazität durch eine einzelne Komponente eingeschränkt, wodurch ein Engpass in der Pipeline entsteht. Die Geschwindigkeit, mit der Daten durch einen Engpass fließen können, begrenzt, wie schnell die Pipeline Eingabedaten akzeptieren und verarbeiten kann.
Betrachten Sie beispielsweise eine Pipeline, in der die DoFn-Verarbeitung nach einem Streaming-Shuffle erfolgt. Eine Warteschlange zwischen den Komponenten puffert die gemischten, aber noch nicht verarbeiteten Daten. Wenn die DoFn-Verarbeitung Daten nicht so schnell verarbeiten kann, wie sie vom Streaming-Shuffle erzeugt werden, wächst die Warteschlange. Ein längerer Engpass kann dazu führen, dass die Warteschlange ihre Kapazität erreicht. An diesem Punkt wird das weitere Shuffling pausiert und der Rückstand breitet sich Upstream aus. Auch in den Warteschlangen weiter Upstream sammeln sich Rückstände an, was schließlich zu einer Verlangsamung führt, die sich bis zur Datenquelle erstreckt. Das bedeutet, dass die gesamte Pipeline nicht mit der Eingabe mithalten kann.
Wenn ein Engpass auftritt, kann ein erheblicher Teil der Pipeline als fehlerhaft angezeigt werden, obwohl der Rückstand nur an einer Stelle in der Pipeline verursacht wird. Dieses Verhalten kann die Fehlerbehebung bei Engpässen erschweren. Ziel der Engpasserkennung ist es, die genaue Position und Ursache zu ermitteln, um Vermutungen zu vermeiden, damit Sie die Ursache beheben können.
Dataflow erkennt einen Engpass, wenn eine Verzögerung den Grenzwert von fünf Minuten überschreitet. Wenn die Verzögerung diesen Grenzwert nicht überschreitet, erkennt Dataflow keinen Engpass.
Die Engpasserkennung erfordert nicht immer Maßnahmen und hängt von Ihrem Anwendungsfall ab. Eine Pipeline kann auch bei vorübergehenden Verzögerungen von mehr als fünf Minuten normal funktionieren. Wenn dies für Ihren Anwendungsfall akzeptabel ist, müssen Sie die angegebenen Engpässe möglicherweise nicht beheben.
Arten von Engpässen
Wenn Dataflow einen Engpass erkennt, wird in der Monitoring-Oberfläche der Schweregrad des Problems angegeben. Engpässe lassen sich in folgende Kategorien unterteilen:
- Verarbeitung hängt und macht keinen Fortschritt
- Der Fortschritt der Pipeline wird an diesem Schritt vollständig angehalten.
- Verarbeitung läuft, gerät aber in Verzug
- Die Pipeline kann eingehende Daten nicht so schnell verarbeiten, wie sie eingehen. Dadurch wächst der Rückstand.
- Verarbeitung läuft, aber Rückstand bleibt unverändert
- Die Pipeline macht Fortschritte und die Verarbeitungsrate ist mit der Eingaberate vergleichbar. Die Verarbeitung ist schnell genug, damit der Rückstand nicht wächst, aber der angesammelte Rückstand wird auch nicht wesentlich reduziert.
- Verarbeitung läuft und holt Rückstand auf
- Der Rückstand wird reduziert, aber der aktuelle Engpass verhindert, dass die Pipeline schneller aufholt. Wenn Sie eine Pipeline mit einem Rückstand starten, ist dieser Zustand möglicherweise normal und erfordert keine Maßnahmen. Beobachten Sie den Fortschritt, um zu sehen, ob der Rückstand weiter abnimmt.
Ursachen für Engpässe
In diesem Abschnitt werden die Ursachen für Engpässe aufgeführt, die erkannt werden können. Mithilfe dieser Informationen können Sie das Problem beheben. In einigen Fällen können mehrere Ursachen vorliegen, die miteinander in Verbindung stehen. Wenn beispielsweise nicht genügend Worker bereitgestellt werden, kann die vCPU-Auslastung hoch sein. Eine hohe vCPU-Auslastung kann dazu führen, dass sich Vorgänge verlangsamen, was wiederum zu einer erhöhten Warteschlangenverzögerung führen kann. In der Analyse der wahrscheinlichen Ursachen werden möglicherweise alle diese Ursachen als Ursachen für den Engpass angezeigt.
- Vorgänge mit langer Verarbeitungszeit
Einige Vorgänge in dieser Berechnung haben eine lange Verarbeitungszeit. Dies tritt immer dann auf, wenn ein Eingabebündel an den Worker gesendet wird, der die
DoFnausführt, und eine erhebliche Zeit vergangen ist, ohne dass Ergebnisse verfügbar sind.Meistens ist die Ursache ein einzelner Vorgang mit langer Ausführungszeit im Nutzercode. Andere Probleme können sich als Vorgänge mit langer Verarbeitungszeit manifestieren. Beispielsweise können Fehler, die in der
DoFnausgelöst und wiederholt werden, Wiederholungen über lange Zeiträume oder Abstürze des Worker-Harness aufgrund von Faktoren wie OOMs zu diesen langen Verarbeitungszeiten führen.Wenn sich die betroffene Berechnung im Nutzercode befindet, suchen Sie nach Möglichkeiten, den Code zu optimieren oder die Ausführungszeit zu begrenzen. Zur Unterstützung bei der Fehlerbehebung enthalten die Worker-Logs Stacktraces für alle Vorgänge, die länger als 5 Minuten hängen.
- Schlüssel-Commit zu groß
- Lange Verarbeitungszeit für alle Vorgänge
Vorgänge in dieser Berechnung dauern immer lange, was auf ein Problem in der vom Nutzer bereitgestellten
DoFnhindeutet.Diese Ursache unterscheidet sich von Vorgängen mit langer Verarbeitungszeit. Während diese Ursache einige Vorgänge betrifft, deutet diese Ursache darauf hin, dass alle Vorgänge in dieser Berechnung betroffen sind.
Prüfen Sie die Worker-Logs auf Fehler, Ausnahmen oder Stacktraces, die auf langsame oder hängende Threads hindeuten. Wenn Sie das Apache Beam SDK für Python verwenden und die Vorgänge von Natur aus lange dauern (z. B. langsame externe API-Aufrufe oder I/O mit hoher Latenz), sollten Sie eine asynchrone DoFnverwenden. Diese Funktion kann den Durchsatz verbessern, indem sie verhindert, dass die Verarbeitung durch diese langwierigen Aufgaben blockiert wird.
- Langsamer Lesevorgang des nichtflüchtigen Zustands
Die Berechnung verbringt einen erheblichen Teil der Zeit mit dem Lesen des nichtflüchtigen Zustands im Rahmen der Ausführung der
DoFn. Dies kann auf einen zu großen nichtflüchtigen Zustand oder zu viele Lesevorgänge zurückzuführen sein. Reduzieren Sie die Größe des nichtflüchtigen Zustands oder die Häufigkeit der Lesevorgänge. Dies kann auch ein vorübergehendes Problem sein, das auf die Langsamkeit des zugrunde liegenden nichtflüchtigen Zustands zurückzuführen ist.- Langsamer Schreibvorgang des nichtflüchtigen Zustands
Die Berechnung verbringt einen erheblichen Teil der Zeit mit dem Schreiben des nichtflüchtigen Zustands während des Commits der Verarbeitungsergebnisse. Dies kann auf einen zu großen nichtflüchtigen Zustand zurückzuführen sein. Reduzieren Sie die Größe des nichtflüchtigen Zustands. Dies kann auch ein vorübergehendes Problem sein, das auf die Langsamkeit des zugrunde liegenden nichtflüchtigen Zustands zurückzuführen ist.
- Abgelehnter Commit
Die Datenverarbeitung kann aufgrund von Ungültigkeit nicht in den nichtflüchtigen Zustand übernommen werden. Dies ist in der Regel auf die Überschreitung eines der Betriebslimits zurückzuführen. Weitere Informationen finden Sie in den Logs oder wenden Sie sich an den Support.
- Unzureichende Apache Kafka-Quellpartitionen
Die Apache Kafka-Quellberechnung hat nicht genügend Partitionen. So beheben Sie das Problem:
- Erhöhen Sie die Anzahl der Kafka-Partitionen.
- Fügen Sie bei der Konfiguration des Kafka-IO-Lesevorgangs
.withRedistribute()ein, um die Daten effizienter zu parallelisieren. Fügen Sie.withRedistributeNumKeys(N)ein, wobeiN > partitionsist, um eine Obergrenze für die Gesamtzahl der Schlüssel festzulegen. Eine begrenzte Anzahl von Schlüsseln sorgt durch die Bündelung von Datensätzen für Effizienz. - Verwenden Sie
.withOffsetDeduplication(), um die Kosten für das Shuffling bei der Neuverteilung zu minimieren. In diesem Modus wird die Datenmenge minimiert, die im Rahmen des Shuffles gespeichert werden muss, während gleichzeitig eine Verarbeitung genau einmal erfolgt.
Weitere Informationen finden Sie unter Parallelität auf der Seite Von Apache Kafka in Dataflow lesen.
- Apache Kafka-Quelle: Große Menge an nichtflüchtigem Zustand
Die Apache Kafka-Quellberechnung verteilt eine große Menge an Daten neu, was zu hoher Latenz und hohen Kosten führen kann. So beheben Sie das Problem:
- Wenn für die Pipeline eine Verarbeitung genau einmal erforderlich ist, minimieren Sie die Kosten für das Shuffling bei der Neuverteilung, indem Sie den Offset-Deduplizierungsmodus verwenden. In diesem Modus wird die Datenmenge minimiert, die im Rahmen des Shuffles gespeichert werden muss, während gleichzeitig eine Verarbeitung genau einmal erfolgt.
- Wenn für die Pipeline eine Verarbeitung mindestens einmal ausreicht, kann die Konfiguration „Duplikate zulassen“ aktiviert werden.
Weitere Informationen finden Sie unter Von Apache Kafka in Dataflow lesen.
- Unzureichende Quellparallelität
Eine Quellberechnung hat nicht genügend Parallelität. Erhöhen Sie nach Möglichkeit die Parallelisierung in der Quelle. Wenn Sie die Parallelisierung nicht erhöhen können und der Job im Modus „Mindestens einmal“ ausgeführt wird, versuchen Sie, der Pipeline eine
RedistributeTransformation hinzuzufügen.- „Heiße“ Schlüssel oder unzureichende Schlüsselparallelität
Der Job hat „heiße“ Schlüssel oder eine unzureichende Schlüsselparallelität.
Für jeden Sharding-Schlüssel verarbeitet Dataflow Nachrichten seriell. Während Dataflow einen Batch von Nachrichten für einen bestimmten Schlüssel verarbeitet, werden andere eingehende Nachrichten für diesen Schlüssel in die Warteschlange gestellt, bis der aktuelle Batch abgeschlossen ist.
Wenn Dataflow nicht genügend unterschiedliche Schlüssel parallel verarbeiten kann, kann dies zu einem Engpass führen. Beispielsweise enthält die Daten möglicherweise zu wenige unterschiedliche Schlüssel oder bestimmte Schlüssel sind in den Daten überrepräsentiert („heiße“ Schlüssel). Weitere Informationen, einschließlich einer Anleitung zum Ermitteln von „heißen“ Schlüsseln, finden Sie unter Fehlerbehebung bei langsamen oder hängenden Streamingjobs.
- Unterdimensionierte vCPUs
Der Job hat nicht genügend Worker-vCPUs. Diese Situation tritt ein, wenn der Job bereits auf das Maximum skaliert wurde, die vCPU-Auslastung hoch ist und es immer noch einen Rückstand gibt. Möglicherweise müssen Sie die maximale Anzahl der für diesen Job bereitgestellten Worker erhöhen. Sie können diese Zahl beispielsweise durch eine Aktualisierung des Autoscaling-Bereichs erhöhen. Alternativ können Sie nach Möglichkeiten suchen, die vCPU-Auslastung durch Änderungen am Pipelinecode oder an der Arbeitslast zu senken. Mit Cloud Profiler können Sie nach Optimierungsmöglichkeiten suchen.
- Hohe vCPU-Auslastung. Warten auf Hochskalierung
Der Job hat eine hohe vCPU-Auslastung, aber es ist noch Platz für eine Hochskalierung. Dieser Zustand ist wahrscheinlich vorübergehend, bis die Hochskalierung erfolgen kann. Sie können das Autoscaling beobachten, um die Autoscaling-Entscheidungen zu sehen. Wenn dieser Zustand längere Zeit anhält oder häufig auftritt, müssen Sie möglicherweise die Autoscaling-Konfiguration ändern, indem Sie einen anderen Hinweis zur Worker-Auslastung festlegen, damit der Job proaktiver hochskaliert werden kann.
- Unausgewogene vCPU-Auslastung verursacht Engpässe bei einigen Ausreißer-Workern
Der Job hat genügend Worker-vCPUs, aber einige Worker weisen eine sehr hohe vCPU-Auslastung auf. Dies wird oft durch eine ungleichmäßige Verteilung der Arbeit verursacht. Mögliche Ursachen sind ungleichmäßig ausgelastete Quellpartitionen oder „heiße“ Schlüssel.
So beheben Sie das Problem:
- Ermitteln Sie die Ursache für die ungleichmäßige Auslastung und versuchen Sie, sie zu beheben. Achten Sie beispielsweise darauf, dass die Quellpartitionen gleichmäßig verteilt sind.
- Wenn es nicht möglich ist, die ungleichmäßige Auslastung zu beheben, können Sie den Worker-VM-Typ ändern, um die Anzahl der vCPUs pro Worker zu erhöhen und die Spitzenlast zu senken. Weitere Informationen zum Konfigurieren der vCPUs pro Worker finden Sie unter Dataflow-Worker-VMs konfigurieren.
- Problem bei der Kommunikation mit Workern
Dataflow kann nicht mit allen Worker-VMs kommunizieren. Prüfen Sie den Status der Worker-VMs des Jobs. Hier einige Gründe dafür:
- Es gibt ein Problem bei der Bereitstellung der Worker-VMs.
- Der Worker-VM-Pool wird gelöscht, während der Job ausgeführt wird.
- Netzwerkprobleme.
- Pub/Sub-Quelle hat Pull-Fehler.
Beim Abrufen von Daten aus der Pub/Sub-Quelle sind Fehler aufgetreten. Prüfen Sie, ob das erforderliche Thema und die erforderlichen Abos vorhanden sind, und prüfen Sie das Kontingent und die Konfiguration. Sie können auch die Logs auf Fehler prüfen.
- Pub/Sub-Quelle hat unzureichende Parallelität
Die Pub/Sub-Quellberechnung hat nicht genügend Pub/Sub-Schlüssel. Um die Anzahl der Schlüssel zu erhöhen, legen Sie die Dienstoption
num_pubsub_keysfest. Weitere Informationen finden Sie unter Pub/Sub-Quellparallelität.- Pub/Sub-Quelle aus unbekanntem Grund gedrosselt
Die Pub/Sub-Quellberechnung wird beim Lesen aus Pub/Sub aus unbekanntem Grund gedrosselt. Dieses Problem ist möglicherweise vorübergehend. Prüfen Sie auf Probleme mit der Pub/Sub-Konfiguration, fehlende IAM-Berechtigungen oder Kontingentlimits. Wenn jedoch keine der oben genannten Ursachen zutrifft und das Problem weiterhin besteht, wenden Sie sich an den Support.
- Veröffentlichung von Pub/Sub-Senken langsam oder hängt
Die Pub/Sub-Senkenberechnung ist langsam oder hängt. Dieses Problem kann durch ein Konfigurationsproblem oder ein Kontingentlimit verursacht werden.
- Lange Wartezeit in der Arbeitswarteschlange
Das Alter der ältesten infrage kommenden Arbeit ist hoch, was auf eine große Anzahl von Schlüsseln und die Geschwindigkeit zurückzuführen ist, mit der Schlüssel verarbeitet werden. In dieser Situation ist jeder Vorgang möglicherweise nicht ungewöhnlich lang, aber die gesamte Warteschlangenverzögerung ist hoch.
Dataflow verwendet einen einzelnen Verarbeitungsthread pro Sharding-Schlüssel und die Anzahl der Verarbeitungsthreads ist begrenzt. Die Warteschlangenverzögerung entspricht ungefähr dem Verhältnis von Schlüsseln zu Threads multipliziert mit der Latenz im Thread für jedes Verarbeitungsbündel für einen Schlüssel:
(key count / total harness threads) * latency per bundleSie können folgende Maßnahmen ergreifen:
- Erhöhen Sie die Anzahl der Worker. Siehe Streaming-Autoscaling.
- Erhöhen Sie die Anzahl der Worker-Harness-Threads. Legen Sie die
numberOfWorkerHarnessThreads/number_of_worker_harness_threadsPipelineoption fest. - Reduzieren Sie die Anzahl der Schlüssel.
- Reduzieren Sie die Latenz des Vorgangs.
- Vorübergehendes Problem mit dem Streaming Engine-Backend
Es gibt ein Konfigurations- oder Betriebsproblem mit dem Streaming Engine-Backend. Dieses Problem ist möglicherweise vorübergehend. Sollte das Problem weiterhin auftreten, wenden Sie sich bitte an den -Support.
- Unbestimmbare Ursache
Die Ursache des Rückstands kann nicht mit Sicherheit ermittelt werden. Dieses Problem ist möglicherweise vorübergehend. Sollte das Problem weiterhin auftreten, wenden Sie sich bitte an den -Support.
Messwerte für Engpässe
Die folgenden Jobmesswerte liefern Informationen zu Engpässen:
job/is_bottleneck: Gibt an, ob eine bestimmte Dataflow-Pipelinestufe ein Engpass ist, zusammen mit der Art des Engpasses und der wahrscheinlichen Ursache.job/backlogged_keys: Die Anzahl der Schlüssel im Rückstand für eine Engpassphase.job/recommended_parallelism: Die empfohlene Parallelität für eine Phase, um Engpässe zu reduzieren.
Nächste Schritte
- Blog zum Engpasserkennungstool mit Beispielen für fehlerhafte Jobs
- Fehlerbehebung bei langsamen oder hängenden Jobs
- Pipelineleistung mit Profiler überwachen