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é :

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

Identifier la cause racine

  1. Vérifiez les métriques Fraîcheur des données et Octets de la file d'attente.

    • Si les deux métriques augmentent de manière monotone, cela signifie que le pipeline est bloqué et ne progresse pas.
    • Si la fraîcheur des données augmente, mais que le nombre d'octets de la file d'attente reste normal, cela signifie qu'un ou plusieurs éléments de travail sont bloqués dans le pipeline.

    Recherchez les étapes où ces métriques augmentent pour identifier les étapes présentant des problèmes et les opérations effectuées à ce stade.

  2. Consultez le graphique de traitement en parallèle pour voir si une étape est bloquée en raison d'un parallélisme faible. Consultez la section Résoudre les problèmes de parallélisme.

  3. Vérifiez les journaux des tâches pour détecter les problèmes tels que les limites de quota, les problèmes de rupture de stock ou l'épuisement des adresses IP.

  4. Recherchez les avertissements et les erreurs dans les journaux des nœuds de calcul.

    • Si les journaux des nœuds de calcul contiennent des erreurs, affichez la trace de la pile. Vérifiez si l'erreur est causée par un bug dans votre code.
    • Recherchez les erreurs Dataflow. Consultez la page Résoudre les erreurs Dataflow.
    • Recherchez les erreurs indiquant que la tâche a dépassé une limite, telle que la taille maximale des messages Pub/Sub.
    • Recherchez les erreurs de mémoire insuffisante, qui peuvent entraîner un blocage du pipeline. Si des erreurs de mémoire insuffisante s'affichent, suivez la procédure décrite dans la section Résoudre les erreurs de mémoire insuffisante Dataflow.
    • Pour identifier une étape lente ou bloquée, recherchez les messages Operation ongoing dans les journaux des nœuds de calcul. Affichez la trace de la pile pour voir où l'étape passe du temps. Pour en savoir plus, consultez la section Traitement bloqué ou opération en cours.

  5. Si un élément de travail est bloqué sur un nœud de calcul spécifique, redémarrez la VM de ce nœud de calcul.

  6. Si vous n'utilisez pas Streaming Engine, recherchez les avertissements et les erreurs dans les journaux du mélangeur. Si une erreur de délai d'expiration RPC s'affiche sur le port 12345 ou 12346, il est possible qu'une règle de pare-feu manque à votre tâche. Consultez la section Règles de pare-feu pour Dataflow.

  7. Recherchez les touches de raccourci.

  8. Si Runner v2 est activé, recherchez d'éventuelles erreurs dans les journaux du harnais. Pour en savoir plus, consultez la page Résoudre les problèmes liés à l'exécuteur v2.

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, consultez 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 :

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.

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.

Recherchez les touches de raccourci à l'aide du filtre de journal suivant:

  resource.type="dataflow_step"
  resource.labels.job_id=JOB_ID
  jsonPayload.line:"hot_key_logger"

Remplacez JOB_ID par l'ID de votre tâche.

Pour résoudre ce problème, effectuez une ou plusieurs des opérations 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 la 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 Google Cloud projet 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 :

  1. Accédez à Google Cloud Console.
  2. Dans le volet de navigation, cliquez sur API et services.
  3. Dans le menu, cliquez sur Bibliothèque.
  4. Utilisez le champ de recherche pour rechercher Pub/Sub.
  5. Cliquez sur API Cloud Pub/Sub.
  6. Cliquez sur Gérer.
  7. 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 :

  1. Dans la console Google Cloud, sélectionnez Surveillance :

    Accéder à Monitoring

  2. Dans le volet de navigation, sélectionnez Explorateur de métriques.

  3. 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 la cause racine

  1. Vérifiez si la tâche rencontre des problèmes lors du démarrage du nœud de calcul. Pour en savoir plus, consultez Erreur lors de la synchronisation du pod.

    Pour vérifier que le job a commencé à traiter les données, recherchez l'entrée de journal suivante dans le journal job-message:

    All workers have finished the startup processes and began to receive work requests

  2. Pour comparer les performances des différents jobs, assurez-vous que le volume de données d'entrée, la configuration des nœuds de calcul, le comportement d'autoscaling et les paramètres de mélange Dataflow sont les mêmes.

  3. Vérifiez les journaux job-message pour détecter d'éventuels problèmes tels que des limites de quota, des problèmes de rupture de stock ou un épuisement des adresses IP.

  4. Dans l'onglet Détails de l'exécution, comparez la progression des étapes pour identifier celles qui ont pris plus de temps.

  5. Recherchez les éléments restants dans la tâche. Pour en savoir plus, consultez la section Résoudre les problèmes liés aux retardataires dans les jobs par lot.

  6. Vérifiez les métriques de débit, de processeur et d'utilisation de la mémoire.

  7. Recherchez les avertissements et les erreurs dans les journaux des nœuds de calcul.

  8. Recherchez les touches de raccourci.

  9. Si vous n'utilisez pas Dataflow Shuffle, vérifiez les journaux du mélangeur pour rechercher les avertissements et les erreurs pendant l'opération de mélange. Si une erreur de délai d'expiration RPC s'affiche sur le port 12345 ou 12346, il est possible qu'une règle de pare-feu manque à votre tâche. Consultez la section Règles de pare-feu pour Dataflow.

  10. Si Runner v2 est activé, recherchez d'éventuelles erreurs dans les journaux du harnais. Pour en savoir plus, consultez la section Résoudre les problèmes liés à l'exécuteur v2.

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 lot.

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 :

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 :

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 de Dataflow, consultez la liste complète des métriques Dataflow dans les métriquesGoogle Cloud .