Résoudre les problèmes liés aux jobs lents ou bloqués

Cette page explique comment résoudre les causes courantes de jobs Dataflow par flux ou par lot lentes ou bloquées.

Flux

Si vous remarquez les symptômes suivants, votre job Dataflow par flux peut s'exécuter lentement ou être bloqué :

Le pipeline ne lit pas les données de la source. Par exemple, Pub/Sub a de plus en plus de tâches en attente.
Le pipeline n'écrit pas de données dans le récepteur.
La métrique de fraîcheur des données augmente.
La métrique de latence du système augmente.

Utilisez les informations fournies dans les sections suivantes pour identifier et diagnostiquer le problème.

Examiner les échecs répétés

Dans un job par flux, certains échecs sont relancés indéfiniment. Ces nouvelles tentatives empêchent le pipeline de progresser. Pour identifier les échecs répétés, consultez les exceptions dans les journaux des nœuds de calcul.

Si l'exception concerne le code utilisateur, déboguez et corrigez le problème dans le code ou dans les données.
Pour éviter que des défaillances inattendues ne bloquent l'exécution de votre pipeline, mettez en œuvre une file d'attente de lettres mortes. Pour un exemple de mise en œuvre, reportez-vous à la page Modèles BigQuery dans la documentation Apache Beam.
Si l'exception est une erreur de mémoire insuffisante (OOM), consultez la page Résoudre les erreurs de mémoire insuffisante Dataflow.
Pour les autres exceptions, consultez la page Résoudre les erreurs Dataflow.

Identifier les nœuds de calcul non opérationnels

Si les nœuds de calcul qui traitent le job par flux ne sont pas opérationnels, le job peut être lent ou sembler bloqué. Pour identifier les nœuds de calcul non opérationnels :

Vérifiez la pression de la mémoire en utilisant les métriques d'utilisation de la mémoire et en recherchant les erreurs de mémoire insuffisante dans les journaux des nœuds de calcul. Pour en savoir plus, consultez la section Résoudre les erreurs Dataflow de mémoire insuffisante.
Si vous utilisez Streaming Engine, identifiez les goulots d'étranglement d'opérations d'entrée/sortie sur le disque (IOPS) à l'aide des métriques de persistance.
Recherchez d'autres erreurs dans les journaux des nœuds de calcul. Pour en savoir plus, consultez les pages Utiliser les journaux de pipeline et Résoudre les erreurs Dataflow.

Identifier les retardataires

Un retardataire est un élément de travail lent par rapport aux autres éléments de travail de l'étape. Pour en savoir plus sur l'identification et la correction des retardataires, consultez la page Résoudre les problèmes de retardataires dans les jobs par flux.

Résoudre les problèmes de parallélisme insuffisant

Pour plus d'évolutivité et d'efficacité, Dataflow exécute les étapes de votre pipeline en parallèle sur plusieurs nœuds de calcul. La plus petite unité de traitement parallèle dans Dataflow est une clé. Les messages entrants pour chaque étape fusionnée sont associés à une clé. La clé est définie de l'une des manières suivantes :

La clé est implicitement définie par les propriétés de la source, (par exemple, les partitions Pub/Sub).
La clé est explicitement définie par la logique d'agrégation dans le pipeline (par exemple, GroupByKey).

Si le pipeline ne dispose pas de suffisamment de clés pour une étape donnée, il limite le traitement en parallèle. Cette étape peut devenir un goulot d'étranglement.

Identifier les étapes avec un faible parallélisme

Pour déterminer si le ralentissement du pipeline est causé par un parallélisme faible, consultez les métriques d'utilisation du processeur. Si l'utilisation est faible, mais répartie uniformément entre les nœuds de calcul, votre job peut présenter un parallélisme insuffisant. Si votre job utilise Streaming Engine, pour voir si une étape présente un parallélisme faible, consultez les métriques de parallélisme dans l'onglet Métriques de job. Pour résoudre ce problème, procédez comme suit :

Dans la console Google Cloud, sur la page Informations sur le job, utilisez l'onglet Autoscaling pour voir si le job rencontre des problèmes pour effectuer un scaling à la hausse. Si l'autoscaling est le problème, consultez la page Résoudre les problèmes liés à l'autoscaling Dataflow.
Utilisez le graphique de job pour vérifier les étapes de la phase. Si l'étape lit depuis une source ou écrit dans un récepteur, consultez la documentation du service de la source ou du récepteur. Consultez la documentation pour déterminer si ce service est configuré pour une évolutivité suffisante.
- Pour collecter plus d'informations, utilisez les métriques d'entrée et de sortie fournies par Dataflow.
- Si vous utilisez Kafka, vérifiez le nombre de partitions Kafka. Pour en savoir plus, consultez la documentation Apache Kafka.
- Si vous utilisez un récepteur BigQuery, activez la segmentation automatique pour améliorer le parallélisme. Pour plus d'informations, consultez la section Tripler le débit Dataflow avec segmentation automatique pour BigQuery.

Rechercher les clés chaudes

Si les tâches sont réparties de manière inégale entre les nœuds de calcul et que l'utilisation est très inégale, votre pipeline peut avoir une clé chaude. Une clé chaude est une clé qui comporte beaucoup plus d'éléments que les autres clés. Pour résoudre ce problème, appliquez une ou plusieurs des étapes suivantes :

Saisissez de nouveau vos données. Pour générer de nouvelles paires clé/valeur, appliquez une transformation ParDo. Pour en savoir plus, consultez la page de la transformation Java ParDo ou la page de la transformation Python ParDo dans le Documentation Apache Beam.
Utilisez .withFanout dans vos transformations combinées Pour en savoir plus, consultez la classe Combine.PerKey dans le SDK Java, ou l'opération with_hot_key_fanout dans le SDK Python.
Si vous disposez d'un pipeline Java qui traite des PCollections illimitées contenant de grands volumes de données, nous vous recommandons d'effectuer les opérations suivantes :
- Utilisez Combine.Globally.withFanout à la place de Combine.Globally.
- Utilisez Combine.PerKey.withHotKeyFanout à la place de Count.PerKey.

Vérifier si le quota est insuffisant

Assurez-vous de disposer d'un quota suffisant pour votre source et votre récepteur. Par exemple, si votre pipeline lit des entrées provenant de Pub/Sub ou de BigQuery, votre projet Google Cloud peut présenter un quota insuffisant. Pour en savoir plus sur les limites de quota pour ces services, consultez les pages Quota Pub/Sub ou Quota BigQuery.

Si votre job génère un nombre élevé d'erreurs 429 (Rate Limit Exceeded), son quota peut être insuffisant. Pour rechercher les erreurs, procédez comme suit :

Accédez à Google Cloud Console.
Dans le volet de navigation, cliquez sur API et services.
Dans le menu, cliquez sur Bibliothèque.
Utilisez le champ de recherche pour rechercher Pub/Sub.
Cliquez sur API Cloud Pub/Sub.
Cliquez sur Gérer.
Dans le graphique Trafic par code de réponse, recherchez des codes d'erreur client (4xx).

Vous pouvez également vérifier l'utilisation des quotas à l'aide de l'explorateur de métriques. Si votre pipeline utilise une source ou un récepteur BigQuery, vous pouvez utiliser les métriques de l'API BigQuery Storage pour résoudre les problèmes de quota. Par exemple, pour créer un graphique indiquant le nombre de connexions BigQuery simultanées, procédez comme suit :

Dans la console Google Cloud, sélectionnez Surveillance :

Accéder à Monitoring
Dans le volet de navigation, sélectionnez Explorateur de métriques.
Dans le volet Sélectionner une métrique, pour Métrique, filtrez sur Projet BigQuery > Écriture > Nombre de connexions simultanées.

Pour obtenir des instructions sur l'affichage des métriques Pub/Sub, consultez la section Surveiller l'utilisation des quotas dans "Surveiller Pub/Sub dans Cloud Monitoring". Pour obtenir des instructions sur l'affichage des métriques BigQuery, consultez la section Afficher l'utilisation et les limites de quota de la page "Créer des tableaux de bord, des graphiques et des alertes".

Lot

Si votre job par lot est lent ou bloqué, utilisez l'onglet Détails de l'exécution pour accéder à davantage d'informations sur le job et identifier l'étape ou le nœud de calcul à l'origine du goulot d'étranglement.

Identifier les retardataires

Identifier les étapes lentes ou bloquées

Pour identifier les étapes lentes ou bloquées, utilisez la vue Progression des étapes. Les barres plus longues indiquent que l'étape prend plus de temps. Utilisez cette vue pour identifier les étapes les plus lentes de votre pipeline.

Une fois que vous avez trouvé l'étape goulot d'étranglement, vous pouvez effectuer les étapes suivantes :

Identifiez le nœud de calcul retardataire dans cette étape.
S'il n'y a pas de nœuds de calcul retardataires, identifiez l'étape la plus lente à l'aide du panneau Informations sur l'étape. Utilisez ces informations pour identifier les candidats à l'optimisation du code utilisateur.
Pour identifier les goulots d'étranglement en parallèle, utilisez les métriques de surveillance Dataflow.

Identifier un nœud de calcul lent

Pour identifier un nœud de calcul lent pour une étape spécifique, utilisez la vue Progression du nœud de calcul. Cette vue indique si tous les nœuds de calcul traitent le travail jusqu'à la fin de l'étape ou si un seul nœud de calcul est bloqué sur une tâche retardataire. Si vous trouvez un nœud de calcul retardataire, procédez comme suit :

Affichez les fichiers journaux de ce nœud de calcul. Pour en savoir plus, consultez la page Surveiller et afficher les journaux de pipeline.
Affichez les métriques d'utilisation du processeur et la progression du nœud de calcul pour les nœuds de calcul retardataires. Si vous constatez une utilisation du processeur inhabituellement faible ou élevée, recherchez les problèmes suivants dans les fichiers journaux de ce nœud de calcul :
- A hot key ... was detected
- Processing stuck ... Operation ongoing

Outils de débogage

Lorsque votre pipeline est lent ou bloqué, les outils suivants peuvent vous aider à diagnostiquer le problème.

Pour mettre en corrélation des incidents et identifier les goulots d'étranglement, utilisez Cloud Monitoring pour Dataflow.
Pour surveiller les performances du pipeline, utilisez Cloud Profiler.
Certaines transformations sont mieux adaptées que d'autres aux pipelines traitant de gros volumes. Les messages de journal peuvent identifier une transformation utilisateur bloquée dans des pipelines de traitement par lot ou par flux.
Pour en savoir plus sur un job bloqué, utilisez les métriques de job Dataflow. La liste suivante inclut des métriques utiles :
- La métrique Octets en attente (backlog_bytes) mesure la quantité d'entrées non traitées, exprimée en octets par étape. Utilisez cette métrique pour identifier une étape fusionnée qui n'a pas de débit. De même, la métrique d'éléments en attente (backlog_elements) mesure le nombre d'éléments d'entrée non traités pour une étape.
- La métrique Traiter des clés en parallèle (processing_parallelism_keys) mesure le nombre de clés de traitement en parallèle par étape spécifique du pipeline au cours des cinq dernières minutes. Utilisez cette métrique pour examiner les éléments suivants :
  - Filtrez le problème sur des étapes spécifiques et confirmez les avertissements de clé chaude, tels que A hot key ... was detected.
  - Identifiez les goulots d'étranglement de débit causés par un parallélisme insuffisant. Ces goulots d'étranglement peuvent ralentir les pipelines ou les bloquer.
- La métrique Retard du système (system_lag) et la métrique de latence du système par étape (per_stage_system_lag) mesurent la durée maximale de traitement ou d'attente de traitement d'un élément de données. Utilisez ces métriques pour identifier les étapes et les goulots d'étranglement inefficaces à partir de sources de données.

Pour obtenir des métriques supplémentaires qui ne sont pas incluses dans l'interface Web de surveillance Dataflow, consultez la liste complète des métriques Dataflow dans Métriques Google Cloud.