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 streaming, les threads de traitement des fonctions définies 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 tâches 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
À cette étape, la progression du pipeline est complètement arrêtée.
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

Cette section liste les causes de goulots d'étranglement qui peuvent être détectées. Utilisez ces informations pour résoudre le problème. Dans certains cas, plusieurs causes peuvent être présentes et liées entre elles. Par exemple, si les nœuds de calcul sont sous-provisionnés, l'utilisation des processeurs virtuels peut être élevée. Une utilisation élevée des vCPU peut ralentir les opérations, ce qui peut entraîner un délai de mise en file d'attente plus long. L'analyse des causes probables peut afficher toutes ces causes comme étant à l'origine du goulot d'étranglement.

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 par des 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 insuffisante 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 excessif 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 une grande partie de son temps à écrire un état persistant lors de l'engagement 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 validé dans 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.
  • Incluez "redistribute" à l'aide de .withRedistribute() lorsque vous configurez la lecture Kafka IO pour paralléliser les données plus efficacement. Incluez .withRedistributeNumKeys(N) où N > partitions pour fournir une limite supérieure au nombre total de clés. Le fait de disposer d'un nombre limité de clés permet d'être plus efficace en regroupant les enregistrements.
  • Pour minimiser le coût du brassage de redistribution, utilisez .withOffsetDeduplication(). Ce mode minimise la quantité de données à conserver dans le cadre du brassage, tout en fournissant un traitement exact.

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

La source Apache Kafka conserve un grand volume d'état persistant

Le calcul de la source Apache Kafka redistribue un volume élevé de données, ce qui peut entraîner une latence et des coûts élevés. Pour résoudre ce problème, essayez les solutions suivantes :

  • Si le traitement "exactement une fois" est requis pour le pipeline, minimisez le coût du brassage de redistribution en utilisant le mode de déduplication des décalages. Ce mode minimise la quantité de données à conserver dans le cadre du brassage, tout en fournissant un traitement exact.
  • Si le traitement au moins une fois est suffisant pour le pipeline, la configuration allow duplicates peut être activée.

Pour en savoir plus, consultez 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. Lorsque 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 d'augmenter la capacité de manière plus proactive.

Charge vCPU déséquilibrée créant des goulots d'étranglement sur certains nœuds de calcul aberrants

Le job dispose de suffisamment de processeurs virtuels de nœud de calcul, mais certains nœuds de calcul affichent une utilisation très élevée des processeurs virtuels. Cela est souvent dû à une répartition inégale du travail. Les causes potentielles incluent des partitions sources chargées de manière inégale ou des touches de raccourci.

Pour résoudre ce problème, procédez comme suit :

  • Déterminez la cause de la charge inégale et essayez de la corriger. Par exemple, assurez-vous que les partitions sources sont réparties de manière égale.
  • Si vous ne pouvez pas corriger la charge inégale, envisagez de modifier la forme de la VM de nœud de calcul pour augmenter le nombre de vCPU par nœud de calcul et réduire l'utilisation maximale. Pour en savoir plus sur la configuration des processeurs virtuels par nœud de calcul, consultez Configurer les VM de nœud de calcul Dataflow.
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 comporte pas assez de clés Pub/Sub. Pour augmenter le nombre de clés, définissez l'option de service num_pubsub_keys. Pour en savoir plus, consultez Parallélisme de la source Pub/Sub.

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 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 de fonctionnement 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.

Cause indéterminée

Il est impossible de déterminer avec certitude la cause de l'accumulation. Il s'agit peut-être d'un problème temporaire. Si le problème persiste, contactez l'assistance.

Métriques de goulot d'étranglement

Les métriques de job suivantes fournissent des informations sur les goulots d'étranglement :

  • job/is_bottleneck : indique si une étape spécifique du pipeline Dataflow est un goulot d'étranglement, ainsi que son type et la cause probable.

  • job/backlogged_keys : nombre de clés en attente pour une étape de goulot d'étranglement.

  • job/recommended_parallelism : parallélisme recommandé pour une étape afin de réduire les goulots d'étranglement.

Étapes suivantes