Fehlerbehebung bei Dataflow-Autoscaling

Auf dieser Seite erfahren Sie, wie Sie Probleme mit den Autoscaling-Features von Dataflow beheben. Außerdem erfahren Sie, wie Sie das Autoscaling verwalten.

Job wird nicht hoch- oder herunterskaliert

Dieser Abschnitt enthält Informationen zu Szenarien, die möglicherweise ein Hoch- oder Herunterskalieren von Workern verhindern.

Streamingjob wird nicht hochskaliert

Wenn Ihre Streamingpipeline einen Rückstand hat, werden die Worker nicht vertikal skaliert.

Dieses Problem tritt auf, wenn der Rückstand weniger als einige Minuten beträgt oder wenn die Worker weniger als 20 % ihrer CPUs verwenden.

Manchmal ist der Rückstand erhöht, die CPU-Auslastung ist jedoch gering. Da einige Aufgaben keine hohe CPU-Auslastung erfordern, wird durch das Hinzufügen von Workern die Leistung nicht verbessert. In diesen Fällen skaliert Dataflow nicht. Weitere Informationen finden Sie unter Streaming-Autoscaling. Dieses Szenario kann folgende Gründe haben:

• Die Pipeline ist E/A-intensiv.
• Die Pipeline wartet auf externe RPC-Aufrufe.
• Heiße Schlüssel verursachen eine ungleichmäßige CPU-Auslastung durch Worker.
• Die Pipeline hat nicht genügend Schlüssel.

Batch- und Streamingjobs skalieren nicht hoch

Der Batch- oder Streamingjob wird wie erwartet ausgeführt. Wenn jedoch mehr Worker benötigt werden, wird der Job nicht hochskaliert.

Dieses Problem kann folgende Ursachen haben:

• Auf die Staging- oder temporären Dateien kann nicht zugegriffen werden. Wenn Ihr Job einen Cloud Storage-Bucket verwendet, verfügt der Bucket möglicherweise über eine Lebenszykluskonfiguration, die Objekte im Bucket löscht. Zu den gelöschten Objekten gehören Staging- und temporäre Ordner und Dateien. Prüfen Sie in der Lebenszykluskonfiguration für den Bucket, ob Dateien gelöscht wurden. Wenn die Staging- oder temporären Ordner oder Dateien nach dem Start des Jobs gelöscht wurden, sind die zum Erstellen neuer Worker erforderlichen Pakete möglicherweise nicht vorhanden. Erstellen Sie die Ordner und Dateien im Bucket neu, um dieses Problem zu beheben.
• Firewallregeln verhindern, dass Worker Traffic an die erforderlichen TCP-Ports senden und empfangen. Firewallregeln können verhindern, dass Worker gestartet werden. Dataflow-Worker müssen Traffic über die TCP-Ports 12345 und 12346 senden und empfangen können. Weitere Informationen, einschließlich der Schritte zur Behebung dieses Problems, finden Sie unter Firewallregeln für Dataflow.
• Eine benutzerdefinierte Quelle hat eine getProgress()-Methode, die einen NULL-Wert zurückgibt. Wenn Sie eine benutzerdefinierte Quelle verwenden, basieren die Rückstandmesswerte auf dem Rückgabewert der getProgress()-Methode Ihrer benutzerdefinierten Quelle, um mit der Datenerfassung zu beginnen. Die Standardimplementierung für getProgress() gibt einen NULL-Wert zurück. Achten Sie zur Behebung dieses Problems darauf, dass Ihre benutzerdefinierte Quelle die Standardmethode getProgress() überschreibt, um einen Nicht-NULL-Wert zurückzugeben.
• Ein durch vertikales Autoscaling ausgelöstes Update deaktiviert das horizontale Autoscaling vorübergehend. Weitere Informationen finden Sie unter Auswirkungen auf horizontales Autoscaling.
• Wenn Sie einen map-Vorgang in einer Python-Pipeline ausführen und Ihr Job nicht hochskaliert wird, müssen Sie möglicherweise eine Reshuffle-Transformation in Ihren Pipelinecode einfügen. Weitere Informationen finden Sie in der Apache Beam-Dokumentation unter Reshuffle.

Streamingjob wird nicht herunterskaliert

Wenn Ihr Streamingjob einen geringen Rückstand und eine niedrige CPU-Auslastung hat, werden die Worker nicht herunterskaliert. Dieses Problem kann verschiedene Ursachen haben.

• Wenn Jobs keine Streaming Engine verwenden, gleicht Dataflow die Anzahl der nichtflüchtigen Speicher zwischen den Workern aus. Daher muss jeder Worker die gleiche Anzahl an nichtflüchtigen Speichern haben. Wenn es beispielsweise 100 Laufwerke und 100 Worker gibt, hat jeder Worker ein Laufwerk. Wenn der Job herunterskaliert wird, kann der Job 50 Worker mit zwei nichtflüchtigen Speichern pro Worker haben. Der Job wird erst wieder herunterskaliert, wenn er 25 Worker mit vier nichtflüchtigen Speichern pro Worker haben kann. Darüber hinaus ist die Mindestanzahl von Workern der Wert, der maxNumWorkers zugewiesen ist, geteilt durch 15. Weitere Informationen finden Sie unter Skalierungsbereich für Streaming-Autoscaling-Pipelines.

• Wenn Jobs Streaming Engine verwenden, basiert das Herunterskalieren auf einer CPU-Zielauslastung von 75 %. Wenn diese CPU-Auslastung nicht erreicht werden kann, ist das Herunterskalieren deaktiviert.

• Die Schätzung des Rückstands muss mindestens zwei Sekunden lang mindestens zwei Minuten dauern, bevor die Worker herunterskaliert werden. Durch Schwankungen des Rückstands kann das Herunterskalieren deaktiviert werden. Darüber hinaus kann ein niedriger Durchsatz die Zeitschätzung verzerren.

• Wenn Ihre Pipeline PeriodicImpulse verwendet, werden Dataflow-Worker nicht wie erwartet herunterskaliert. Die Verwendung von PeriodicImpulse wird beim Streaming-Autoscaling nicht unterstützt.

Hochskalierungen

Der Batch- oder Streamingjob beginnt mit der Hochskalierung, die Worker beenden jedoch die Skalierung, obwohl ein Rückstand bleibt.

Dieses Problem tritt auf, wenn Kontingentlimits erreicht werden.

• Compute Engine-Kontingente: Dataflow-Jobs unterliegen dem Compute Engine-Kontingent des Projekts. Wenn mehrere Jobs ausgeführt werden, überschreitet das Projekt möglicherweise das Limit seines Compute Engine-Kontingents. In diesem Fall kann Dataflow die Anzahl der Worker nicht erhöhen.
• CPU-Kontingente: Dataflow-Jobs unterliegen auch dem CPU-Kontingent des Projekts. Wenn der Worker-Typ mehr als eine CPU verwendet, liegt das Projekt möglicherweise am Limit des CPU-Kontingents.
• Kontingente für externe IP-Adressen: Wenn Ihr Job externe IP-Adressen für die Kommunikation mit Ressourcen verwendet, benötigen Sie so viele externe IP-Adressen wie Worker. Wenn die Anzahl der Worker vertikal skaliert wird, erhöht sich auch die Anzahl der externen IP-Adressen. Wenn das IP-Adresslimit erreicht ist, beenden die Worker das Hochskalieren.

Wenn die von Ihnen ausgewählte Region aus einer Ressource stammt, können Sie keine neuen Ressourcen dieses Typs erstellen, auch wenn in Ihrer Region oder Ihrem Projekt noch ein Kontingent vorhanden ist. Beispiel: Ihr Kontingent zum Erstellen externer IP-Adressen in us-central1 ist noch nicht aufgebraucht, aber in dieser Region sind keine IP-Adressen verfügbar. Weitere Informationen finden Sie unter Kontingente und Ressourcenverfügbarkeit.

Fordern Sie eine Kontingenterhöhung an oder führen Sie den Job in einer anderen Region aus, um dieses Problem zu beheben.

Der Hinweis zur Worker-Auslastung hat keine Auswirkungen

Sie legen den Hinweis zur Auslastung von Arbeitsthreads fest, das Autoscaling-Verhalten ändert sich jedoch nicht.

Rufen Sie das Diagramm CPU-Auslastung der Worker auf und prüfen Sie, ob der Hinweis zur Worker-Auslastung aktiv verwendet wird. Wenn der Hinweis verwendet wird, wird im Diagramm CPU utilization hint (actively used by autoscaler) angezeigt. Andernfalls wird CPU utilization hint (not actively used by autoscaler) angezeigt.

Der Auslastungshinweis ist nur einer der Faktoren, die sich auf das Autoscaling auswirken. In der folgenden Tabelle sind einige Gründe dafür aufgeführt, warum der Autoscaler den Hinweis möglicherweise nicht aktiv verwendet:

Beobachtetes Skalierungsverhalten	Ursachen	Zu prüfende Messwerte
Keine Änderung	Sie haben die Mindest- oder Höchstzahl der Worker erreicht. Die Anzahl der Worker wird durch die Anzahl der parallel verarbeiteten Schlüssel begrenzt. Jobs werden durch externe RPCs gedrosselt. Die Herunterskalierung ist zu klein oder Dataflow führt eine Dämpfung der Herunterskalierung durch. Weitere Informationen finden Sie unter Streaming-Autoscaling-Heuristik.	job/aggregated_worker_utilization job/max_worker_instances_limit job/min_worker_instances_limit job/processing_parallelism_keys RPC-Fehler, die in Worker-Fehlerprotokollen gemeldet werden In Worker-Logs gemeldete Abstürze
Hochskalieren	Ein Ziel mit hohem Rückstand oder hoher Latenz überschreibt den Hinweis. Die Mindestanzahl der Worker wurde auf einen höheren Wert als die aktuelle Anzahl der Worker aktualisiert.	job/aggregated_worker_utilization job/backlog_bytes job/backlog_elements job/estimated_timer_backlog_processing_time job/min_worker_instances_limit
Herunterskalieren	Die maximale Anzahl von Workern wurde auf einen Wert aktualisiert, der niedriger als die aktuelle Anzahl von Workern ist.	job/aggregated_worker_utilization job/max_worker_instances_limit

Weitere Informationen finden Sie unter Streaming-Autoscaling-Heuristik.

Lücken in Autoscaling-Messwerten

Es gibt kurze, vorübergehende Lücken bei den Autoscaling-Messwerten.

Dieses Problem kann auftreten, wenn Backend-Aufgaben neu gestartet werden. Diese Lücken in den Messwerten weisen nicht auf ein Problem mit dem Autoscaling oder der Zuverlässigkeit des Streamingjobs hin.

CPU ist ungleichmäßig verteilt

Beim Autoscaling des Jobs wird die CPU-Auslastung ungleichmäßig auf die Worker verteilt. Einige Worker haben eine höhere CPU-Auslastung, Systemlatenz oder Datenaktualität als andere.

Dieses Problem kann auftreten, wenn Ihre Daten einen "heißen" Schlüssel enthalten. Ein „heißer” Schlüssel ist ein Schlüssel mit so vielen Elementen, dass es sich negativ auf die Pipeline-Leistung auswirkt. Jeder Schlüssel muss von einem einzelnen Worker verarbeitet werden, sodass die Arbeit nicht auf Worker aufgeteilt werden kann.

Weitere Informationen finden Sie in den Hinweisen zu fehlerhaften „heißen” Schlüsseln.

Das Arbeitselement, das den Zustand anfordert, ist im Backend nicht mehr gültig.

Während der Kommunikation zwischen Worker-VM-Instanzen und Streaming Engine-Aufgaben in einer Streaming-Pipeline tritt der folgende Fehler auf:

The work item requesting state read is no longer valid on the backend.
The work has already completed or will be retried.
This is expected during autoscaling events.

Während des Autoscalings kommunizieren Worker-VM-Instanzen mit mehreren Streaming Engine-Aufgaben und jede Aufgabe stellt mehrere Worker-VM-Instanzen bereit. Elementschlüssel werden zur Verteilung der Arbeit verwendet. Jede Aufgabe und Worker-VM-Instanz hat eine Sammlung von Schlüsselbereichen und die Verteilung dieser Bereiche kann sich dynamisch ändern. Während der automatischen Skalierung kann beispielsweise die Größenanpassung des Jobs dazu führen, dass sich die Verteilung des Schlüsselbereichs ändert. Wenn sich ein Schlüsselbereich ändert, kann dieser Fehler auftreten. Der Fehler wird erwartet. Wenn Sie keine Korrelation zwischen diesen Nachrichten und einer leistungsschwachen Pipeline feststellen, können Sie sie ignorieren.

Unzureichende Streaming Engine-Ressourcen

Wenn die Streaming Engine die von Ihnen angeforderte Mindestanzahl von Workern nicht zuweisen kann, wird der folgende Fehler zurückgegeben:

Streaming Engine does not currently have enough resources available to fulfill
the request.

Legen Sie eine kleinere Mindestanzahl von Workern fest, um dieses Problem zu beheben. Weitere Informationen finden Sie unter Autoscaling-Bereich festlegen.

Skalierungsbereich für Streaming-Autoscaling-Pipelines

Dieser Abschnitt enthält Details zum Skalierungsbereich für Streaming-Autoscaling-Pipelines.

Java

Bei Streaming-Autoscaling-Jobs, die nicht Streaming Engine verwenden, werden jedem Worker vom Dataflow-Dienst 1 bis 15 nichtflüchtige Speicher zugeordnet. Die Mindestanzahl der Worker, die für eine Streaming-Autoscaling-Pipeline verwendet werden, ist also N/15, wobei N der Wert von --maxNumWorkers ist.

Für Streaming-Autoscaling-Jobs, die Streaming Engine verwenden, ist die Mindestanzahl von Workern 1.

Dataflow gleicht die Anzahl der nichtflüchtigen Speicher zwischen den Workern aus. Wenn die Pipeline beispielsweise im stabilen Zustand drei oder vier Worker benötigt, können Sie --maxNumWorkers=15 festlegen. Die Pipeline führt in diesem Fall automatisch eine Skalierung zwischen 1 und 15 Workern durch. Dabei werden 1, 2, 3, 4, 5, 8 oder 15 Worker verwendet, die jeweils 15, 8, 5, 4, 3, 2 oder 1 nichtflüchtige(n) Speicher pro Worker entsprechen.

--maxNumWorkers kann maximal 1000 sein.

Python

Bei Streaming-Autoscaling-Jobs, die nicht Streaming Engine verwenden, werden jedem Worker vom Dataflow-Dienst 1 bis 15 nichtflüchtige Speicher zugeordnet. Die Mindestanzahl der Worker, die für eine Streaming-Autoscaling-Pipeline verwendet werden, ist also N/15, wobei N der Wert von --max_num_workers ist.

Für Streaming-Autoscaling-Jobs, die Streaming Engine verwenden, ist die Mindestanzahl von Workern 1.

Dataflow gleicht die Anzahl der nichtflüchtigen Speicher zwischen den Workern aus. Wenn die Pipeline beispielsweise im stabilen Zustand drei oder vier Worker benötigt, können Sie --max_num_workers=15 festlegen. Die Pipeline führt in diesem Fall automatisch eine Skalierung zwischen 1 und 15 Workern durch. Dabei werden 1, 2, 3, 4, 5, 8 oder 15 Worker verwendet, die jeweils 15, 8, 5, 4, 3, 2 oder 1 nichtflüchtige(n) Speicher pro Worker entsprechen.

--max_num_workers kann maximal 1000 sein.

Go

Bei Streaming-Autoscaling-Jobs, die nicht Streaming Engine verwenden, werden jedem Worker vom Dataflow-Dienst 1 bis 15 nichtflüchtige Speicher zugeordnet. Die Mindestanzahl der Worker, die für eine Streaming-Autoscaling-Pipeline verwendet werden, ist also N/15, wobei N der Wert von --max_num_workers ist.

Für Streaming-Autoscaling-Jobs, die Streaming Engine verwenden, ist die Mindestanzahl von Workern 1.

Dataflow gleicht die Anzahl der nichtflüchtigen Speicher zwischen den Workern aus. Wenn die Pipeline beispielsweise im stabilen Zustand drei oder vier Worker benötigt, können Sie --max_num_workers=15 festlegen. Die Pipeline führt in diesem Fall automatisch eine Skalierung zwischen 1 und 15 Workern durch. Dabei werden 1, 2, 3, 4, 5, 8 oder 15 Worker verwendet, die jeweils 15, 8, 5, 4, 3, 2 oder 1 nichtflüchtige(n) Speicher pro Worker entsprechen.

--max_num_workers kann maximal 1000 sein.

Maximale Anzahl der Worker, die Autoscaling für Streaming verwenden können

Java

Die Ausführung von Dataflow wird durch das Compute Engine-Kontingent für die Instanzanzahl für Ihr Projekt oder durch maxNumWorkers begrenzt, je nachdem, welcher Wert geringer ist.

Python

Die Ausführung von Dataflow wird durch das Compute Engine-Kontingent für die Instanzanzahl für Ihr Projekt oder durch max_num_workers begrenzt, je nachdem, welcher Wert geringer ist.

Go

Die Ausführung von Dataflow wird durch das Compute Engine-Kontingent für die Instanzanzahl für Ihr Projekt oder durch max_num_workers begrenzt, je nachdem, welcher Wert geringer ist.

Autoscaling begrenzen, um die Auswirkungen auf die Abrechnung zu reduzieren

Wenn Sie nicht möchten, dass das Autoscaling Ihre Rechnung erhöht, können Sie die maximale Anzahl der Worker begrenzen, die der Streamingjob verwenden kann.

Java

Indem Sie --maxNumWorkers festlegen, begrenzen Sie den Skalierungsbereich, der zur Verarbeitung Ihres Jobs verwendet wird.

Python

Indem Sie --max_num_workers festlegen, begrenzen Sie den Skalierungsbereich, der zur Verarbeitung Ihres Jobs verwendet wird.

Go

Indem Sie --max_num_workers festlegen, begrenzen Sie den Skalierungsbereich, der zur Verarbeitung Ihres Jobs verwendet wird.

Skalierungsbereich ändern

Informationen zum Ändern des Skalierungsbereichs einer Streamingpipeline finden Sie unter Autoscaling-Bereich festlegen.

Autoscaling für Streamingpipelines deaktivieren

Führen Sie die folgenden Schritte aus, um Autoscaling in der Streamingpipeline zu deaktivieren.

Java

Legen Sie dazu --autoscalingAlgorithm=NONE fest. Weitere Informationen finden Sie unter Horizontales Autoscaling deaktivieren.

Python

Legen Sie dazu --autoscaling_algorithm=NONE fest. Weitere Informationen finden Sie unter Horizontales Autoscaling deaktivieren.

Go

Legen Sie dazu --autoscaling_algorithm=NONE fest. Weitere Informationen finden Sie unter Horizontales Autoscaling deaktivieren.

Feste Anzahl von Workern verwenden

Bei Streamingjobs ohne Streaming Engine wird standardmäßig eine feste Anzahl von Workern verwendet. Wenn Sie Streaming-Autoscaling mit diesen Pipelines verwenden möchten, müssen Sie es explizit aktivieren, da es standardmäßig nicht aktiviert ist.