Résoudre les problèmes de goulots d'étranglement dans Dataflow

Un goulot d'étranglement se produit lorsqu'une étape, une phase ou un nœud de calcul ralentit l'ensemble du job. Les goulots d'étranglement peuvent entraîner l'inactivité des nœuds de calcul et une latence accrue.

Si Dataflow détecte un goulot d'étranglement, le graphique du job affiche une alerte et le panneau Infos sur l'étape indique le type de goulot d'étranglement et la cause, si elle est connue. Dataflow exporte également les informations de détection des goulots d'étranglement vers une métrique Stackdriver, qui présente les données sous forme de série temporelle. Cela vous permet d'identifier les goulots d'étranglement au fil du temps ou dans le passé.

Comprendre les goulots d'étranglement

Lorsqu'il exécute un pipeline de streaming, le job Dataflow se compose d'une série de composants, tels que les shuffles de flux, les threads de traitement de la fonction définie par l'utilisateur (DoFn) et le checkpointing d'état persistant. Pour faciliter le flux de données, Dataflow utilise des files d'attente pour connecter ces composants. Les données sont transférées de l'amont vers l'aval.

Dans de nombreux pipelines, la capacité de débit globale est limitée par un seul composant, ce qui crée un goulot d'étranglement dans le pipeline. La vitesse à laquelle les données peuvent transiter par un goulot d'étranglement limite la vitesse à laquelle le pipeline peut accepter et traiter les données d'entrée.

Par exemple, considérons un pipeline où le traitement DoFn se produit en aval d'un shuffle de flux. Une file d'attente entre eux met en mémoire tampon les données mélangées, mais non traitées. Si le traitement DoFn ne peut pas consommer les données aussi rapidement que le shuffle en flux continu les produit, la file d'attente augmente. Un goulot d'étranglement prolongé peut entraîner la saturation de la file d'attente. À ce stade, le mélange est mis en pause et le backlog est propagé en amont. Les files d'attente en amont accumulent également des éléments en attente, ce qui finit par entraîner un ralentissement qui s'étend à la source de données. Cela signifie que l'ensemble du pipeline ne peut pas suivre le rythme de l'entrée.

Lorsqu'un goulot d'étranglement se produit, une partie importante du pipeline peut sembler non opérationnelle, même si un seul point du pipeline est à l'origine du backlog. Ce comportement peut rendre difficile le débogage des goulots d'étranglement. L'objectif de la détection des goulots d'étranglement est d'identifier l'emplacement et la cause exacts, en éliminant les conjectures, afin que vous puissiez résoudre la cause racine.

Dataflow détecte un goulot d'étranglement lorsqu'un délai dépasse le seuil de cinq minutes. Si le délai ne dépasse pas ce seuil, Dataflow ne détecte pas de goulot d'étranglement.

La détection des goulots d'étranglement ne nécessite pas toujours une action de votre part et dépend de votre cas d'utilisation. Un pipeline peut fonctionner normalement avec des retards temporaires de plus de cinq minutes. Si cela est acceptable pour votre cas d'utilisation, vous n'aurez peut-être pas besoin de résoudre les goulots d'étranglement indiqués.

Types de goulots d'étranglement

Lorsque Dataflow détecte un goulot d'étranglement, l'interface de surveillance indique la gravité du problème. Les goulots d'étranglement se répartissent dans les catégories suivantes :

Le traitement est bloqué et ne progresse pas
La progression du pipeline est complètement arrêtée à cette étape.
Le traitement est en cours, mais il est en retard.
Le pipeline ne peut pas traiter les données entrantes aussi rapidement qu'elles arrivent. Le backlog s'en trouve donc allongé.
Le traitement est en cours, mais le nombre d'éléments en attente reste stable.
Le pipeline progresse et le taux de traitement est comparable au taux d'entrée. Le traitement est suffisamment rapide pour que le nombre d'éléments en attente n'augmente pas, mais il ne diminue pas non plus de manière significative.
Le traitement est en cours et rattrape le retard accumulé.
Le backlog diminue, mais le goulot d'étranglement actuel empêche le pipeline de rattraper son retard plus rapidement. Si vous démarrez un pipeline avec un backlog, cet état peut être normal et ne nécessiter aucune intervention. Surveillez la progression pour voir si le backlog continue de diminuer.

Causes des goulots d'étranglement

L'interface de surveillance indique la cause du goulot d'étranglement, si elle est connue. Utilisez ces informations pour résoudre le problème.

Opérations de traitement de longue durée

Le calcul prend beaucoup de temps. Cela se produit chaque fois qu'un bundle d'entrée est envoyé au nœud de calcul exécutant DoFn et qu'un temps important s'est écoulé sans que des résultats soient disponibles.

Cela est le plus souvent dû à une seule opération de longue durée dans le code utilisateur. D'autres problèmes peuvent se manifester sous la forme d'opérations de traitement de longue durée. Par exemple, les erreurs générées et réessayées dans DoFn, les nouvelles tentatives pendant de longues périodes ou les plantages du harnais de nœud de calcul dus à des facteurs tels que les erreurs de mémoire saturée peuvent tous entraîner ces longs temps de traitement.

Si le calcul concerné se trouve dans le code utilisateur, cherchez des moyens d'optimiser le code ou de limiter le temps d'exécution. Pour faciliter le débogage, les journaux du worker affichent des traces de pile pour toutes les opérations bloquées pendant plus de cinq minutes.

Lecture lente de l'état persistant

Le calcul passe une partie importante de son temps à lire l'état persistant lors de l'exécution de DoFn. Cela peut être dû à un état persistant excessivement volumineux ou à un nombre trop important de lectures. Envisagez de réduire la taille de l'état persistant ou la fréquence des lectures. Il peut également s'agir d'un problème temporaire dû à la lenteur de l'état persistant sous-jacent.

Écriture lente de l'état persistant

Le calcul passe beaucoup de temps à écrire un état persistant lors de la validation des résultats du traitement. Cela peut être dû à un état persistant excessivement volumineux. Envisagez de réduire la taille de l'état persistant. Il peut également s'agir d'un problème temporaire dû à la lenteur de l'état persistant sous-jacent.

Commit refusé

Le traitement des données ne peut pas être appliqué à un état persistant, car il n'est pas valide. Cela est généralement dû au dépassement d'une des limites opérationnelles. Consultez les journaux pour en savoir plus ou contactez l'assistance.

Nombre insuffisant de partitions sources Apache Kafka

Le calcul de la source Apache Kafka ne comporte pas assez de partitions. Pour résoudre ce problème, essayez les solutions suivantes :

  • Augmentez le nombre de partitions Kafka.
  • Utilisez une transformation Redistribute pour redistribuer et paralléliser les données plus efficacement.

Pour en savoir plus, consultez la section Parallélisme de la page Lire des données depuis Apache Kafka vers Dataflow.

Parallélisme de la source insuffisant

Le parallélisme d'un calcul de source est insuffisant. Si possible, augmentez la parallélisation dans la source. Si vous ne pouvez pas augmenter la parallélisation et que le job utilise le mode "au moins une fois", essayez d'ajouter une transformation Redistribute au pipeline.

Clés surutilisées ou parallélisme de clés insuffisant

Le job présente des clés surutilisées ou un parallélisme de clés insuffisant.

Pour chaque clé de partitionnement, Dataflow traite les messages de manière séquentielle. Pendant que Dataflow traite un lot de messages pour une clé donnée, les autres messages entrants pour cette clé sont mis en file d'attente jusqu'à ce que le lot actuel soit terminé.

Si Dataflow ne peut pas traiter suffisamment de clés distinctes en parallèle, cela peut entraîner un goulot d'étranglement. Par exemple, les données peuvent comporter trop peu de clés distinctes ou certaines clés peuvent être surreprésentées dans les données ("clés actives"). Pour en savoir plus, consultez Résoudre les problèmes liés aux jobs de traitement en flux continu lents ou bloqués.

vCPU sous-provisionnés

Le job ne dispose pas d'assez de processeurs virtuels de nœud de calcul. Cette situation se produit lorsque la tâche est déjà mise à l'échelle au maximum, que l'utilisation des processeurs virtuels est élevée et qu'il existe toujours un backlog. Vous devrez peut-être augmenter le nombre maximal de nœuds de calcul provisionnés pour ce job. Par exemple, vous pouvez augmenter ce nombre en mettant à jour la plage d'autoscaling. Vous pouvez également chercher des moyens de réduire l'utilisation des processeurs virtuels en modifiant le code du pipeline ou la charge de travail. Vous pouvez utiliser Cloud Profiler pour rechercher des opportunités d'optimisation.

Utilisation élevée des vCPU, en attente d'un scaling à la hausse

La tâche a une utilisation élevée des vCPU, mais il est possible de faire un scaling à la hausse. Cette condition est probablement temporaire jusqu'à ce que la mise à l'échelle puisse avoir lieu. Vous pouvez surveiller l'autoscaling pour voir les décisions d'autoscaling. Si cette condition persiste longtemps ou se produit fréquemment, vous devrez peut-être modifier la configuration de l'autoscaling en définissant un autre indice d'utilisation des nœuds de calcul pour permettre au job de faire évoluer l'échelle de manière plus proactive.

Problème de communication avec les nœuds de calcul

Dataflow ne peut pas communiquer avec toutes les VM de nœud de calcul. Vérifiez l'état des VM de calcul du job. Les causes possibles sont les suivantes :

  • Un problème est survenu lors du provisionnement des VM de nœud de calcul.
  • Le pool de VM de nœuds de calcul est supprimé pendant l'exécution du job.
  • Problèmes de Mise en réseau.
La source Pub/Sub présente des erreurs de récupération.

Des erreurs se sont produites lors de la récupération des données à partir de la source Pub/Sub. Vérifiez que le sujet et les abonnements requis existent, et vérifiez le quota et la configuration. Vous pouvez également rechercher des erreurs dans les journaux.

La source Pub/Sub présente un parallélisme insuffisant

Le calcul de la source Pub/Sub ne dispose pas d'un nombre suffisant de clés Pub/Sub. Si cet avertissement s'affiche, contactez l'assistance.

La source Pub/Sub est limitée pour une raison inconnue

Le calcul de la source Pub/Sub est limité lors de la lecture à partir de Pub/Sub, pour une raison inconnue. Il s'agit peut-être d'un problème temporaire. Vérifiez s'il existe des problèmes de configuration Pub/Sub, des autorisations IAM manquantes ou des limites de quota. Toutefois, si aucune des causes précédentes n'est à l'origine du problème et que celui-ci persiste, contactez l'assistance.

La publication au niveau du récepteur Pub/Sub est lente ou bloquée

Le calcul du récepteur Pub/Sub est lent ou bloqué. Ce problème peut être dû à un problème de configuration ou à une limite de quota.

Temps de file d'attente élevé

L'âge de travail éligible le plus ancien est élevé en raison du grand nombre de clés et de la vitesse à laquelle elles sont traitées. Dans ce cas, chaque opération n'est pas forcément anormalement longue, mais le délai d'attente global est élevé.

Dataflow utilise un seul thread de traitement par clé de partitionnement, et le nombre de threads de traitement est limité. Le délai de mise en file d'attente est approximativement égal au ratio entre les clés et les threads, multiplié par la latence sur le thread pour chaque bundle de traitement d'une clé :

(key count / total harness threads) * latency per bundle

Essayez les solutions suivantes :

  • Augmentez le nombre de nœuds de calcul. Consultez la section Autoscaling des flux.
  • Augmentez le nombre de threads de faisceau de nœud de calcul. Définissez l'option de pipeline numberOfWorkerHarnessThreads / number_of_worker_harness_threads.
  • Diminuez le nombre de clés.
  • Réduisez la latence des opérations.
Problème temporaire avec le backend Streaming Engine

Un problème de configuration ou opérationnel est survenu avec le backend Streaming Engine. Il s'agit peut-être d'un problème temporaire. Si le problème persiste, contactez l'assistance.

Étapes suivantes