Guidage d'erreur commun

Cette page décrit certaines erreurs courantes que vous pouvez rencontrer lors de l'exécution de votre tâche Cloud Dataflow, et suggère des mesures à prendre pour corriger ces erreurs.

Messages des tâches :

Erreurs d'envoi des tâches :

Journaux des nœuds de calcul (Stackdriver) :

Messages des tâches

"La tâche a échoué car un élément de travail a échoué quatre fois."

Si une seule opération entraîne l'échec du code de nœud de calcul à quatre reprises, par le code qui génère une exception ou provoque une panne, Cloud Dataflow fait échouer la tâche et le message a work item failed 4 times est affiché.

Recherchez les quatre échecs un par un dans les journaux Stackdriver. Recherchez des entrées de journal de niveau Erreur ou de niveau Fatal dans les journaux des nœuds de calcul qui affichent des exceptions ou des erreurs. Vous devez voir au moins quatre de ces exceptions ou erreurs.

Erreurs d'encodage, exceptions IOException ou comportement inattendu dans le code utilisateur.

Les SDK Apache Beam et les nœuds de calcul Cloud Dataflow dépendent de composants tiers courants. Ces composants importent des dépendances supplémentaires. Les conflits de version peuvent entraîner un comportement inattendu au niveau du service. Si vous utilisez l'un de ces packages dans votre code, sachez que certaines bibliothèques peuvent ne pas offrir une compatibilité ascendante. Vous devrez peut-être épingler les versions incluses dans le champ d'application pendant l'exécution. La page Dépendances des SDK et des nœuds de calcul contient la liste des dépendances et des versions requises associées.

Des tâches qui fonctionnaient auparavant échouent avec le message d'erreur "Le paquet intermédiaire (...) est inaccessible"

Vérifiez que le bucket Cloud Storage utilisé pour la préproduction ne présente pas de paramètres TTL (Time To Live) entraînant la suppression des packages préproduits.

Erreurs d'envoi des tâches

"413 Corps de requête trop long / La taille de la représentation JSON sérialisée du pipeline dépasse la limite autorisée."

Si vous rencontrez une erreur liée à la charge utile JSON lors de l'envoi de votre tâche, cela signifie que la représentation JSON de votre pipeline dépasse la taille de requête maximale, fixée à 20 Mo. Ces erreurs peuvent être signalées par l'un des messages suivants dans la fenêtre de la console ou du terminal :

  • 413 Request Entity Too Large
  • "The size of serialized JSON representation of the pipeline exceeds the allowable limit" (La taille de la représentation JSON sérialisée du pipeline dépasse la limite autorisée)
  • "Failed to create a workflow job: Invalid JSON payload received" (Échec de la création d'une tâche de workflow : la charge utile JSON reçue n'est pas valide)
  • "Failed to create a workflow job: Request payload exceeds the allowable limit" (Échec de la création d'une tâche de workflow : la charge utile de la requête dépasse la limite autorisée)

La taille de votre tâche est spécifiquement liée à la représentation JSON du pipeline. Plus le pipeline est grand, plus la taille de la requête est importante. Cloud Dataflow limite actuellement la taille des requêtes à 20 Mo.

Pour estimer la taille de la requête JSON correspondant à votre pipeline, exécutez celui-ci avec l'option suivante :

Java : SDK 2.x

--dataflowJobFile=< path to output file >

Python

--dataflow_job_file=< path to output file >

Java : SDK 1.x

--dataflowJobFile=< path to output file >

Cette commande écrit une représentation JSON de votre tâche dans un fichier. La taille du fichier sérialisé fournit une bonne approximation de la taille de la requête, sachant que la taille réelle sera légèrement supérieure du fait de l'inclusion d'informations supplémentaires dans la requête.

Certaines caractéristiques de votre pipeline peuvent amener la représentation JSON à dépasser la limite. Les facteurs de dépassement les plus courants sont les suivants :

  • Une transformation Create incluant une grande quantité de données en mémoire.
  • Une instance DoFn volumineuse sérialisée pour transmission aux nœuds de calcul distants
  • Une fonction DoFn définie comme une instance d'une classe interne anonyme, et qui intègre (peut-être par inadvertance) une grande quantité de données à sérialiser

Pour éviter ces situations, envisagez de restructurer votre pipeline.

"Le graphique de la tâche est trop grand. Veuillez réessayer avec un graphique de tâche plus petit, ou diviser votre tâche en deux plus petites tâches (ou plus)."

La taille du graphique de votre tâche ne doit pas dépasser 10 Mo. Certaines conditions existantes dans votre pipeline peuvent entraîner un dépassement de la limite de la part du graphique. Les facteurs de dépassement les plus courants sont les suivants :

  • Une transformation Create incluant une grande quantité de données en mémoire.
  • Une instance DoFn volumineuse sérialisée pour transmission aux nœuds de calcul distants
  • Une fonction DoFn définie comme une instance d'une classe interne anonyme, et qui intègre (peut-être par inadvertance) une grande quantité de données à sérialiser

Pour éviter ces situations, envisagez de restructurer votre pipeline.

"Le nombre total d'objets BoundedSource générés par l'opération splitIntoBundles() dépasse la limite autorisée." ou "La taille totale des objets BoundedSource générés par l'opération splitIntoBundles() dépasse la limite autorisée)."

Java : SDK 2.x

Cette erreur est susceptible de se produire lorsque vous lisez des données à partir d'un très grand nombre de fichiers via TextIO, AvroIO ou une autre source basée sur des fichiers. La limite exacte dépend des détails de votre source (par exemple, l'intégration de schémas dans AvroIO.Read limite le nombre de fichiers autorisés), mais elle est de l'ordre de plusieurs dizaines de milliers de fichiers par pipeline.

Vous pouvez également rencontrer cette erreur si vous avez créé une source de données personnalisée pour votre pipeline et que la méthode splitIntoBundles de votre source a renvoyé une liste d'objets BoundedSource qui occupe plus de 20 Mo une fois sérialisée.

La limite autorisée pour la taille totale des objets BoundedSource générés par l'opération splitIntoBundles() de votre source personnalisée est de 20 Mo. Vous pouvez contourner cette limitation en modifiant votre sous-classe BoundedSource personnalisée de telle sorte que la taille totale des objets BoundedSource générés soit inférieure à cette limite de 20 Mo. Par exemple, votre source pourrait générer un nombre réduit de divisions initiales et s'appuyer sur le rééquilibrage dynamique du travail pour fractionner davantage les entrées à la demande.

Java : SDK 1.x

Cette erreur est susceptible de se produire lorsque vous lisez des données à partir d'un très grand nombre de fichiers via TextIO, AvroIO ou une autre source basée sur des fichiers. La limite exacte dépend des détails de votre source (par exemple, l'intégration de schémas dans AvroIO.Read limite le nombre de fichiers autorisés), mais elle est de l'ordre de plusieurs dizaines de milliers de fichiers par pipeline.

Vous pouvez également rencontrer cette erreur si vous avez créé une source de données personnalisée pour votre pipeline et que la méthode splitIntoBundles de votre source a renvoyé une liste d'objets BoundedSource qui occupe plus de 20 Mo une fois sérialisée.

La limite autorisée pour la taille totale des objets BoundedSource générés par l'opération splitIntoBundles() de votre source personnalisée est de 20 Mo. Vous pouvez contourner cette limitation en modifiant votre sous-classe BoundedSource personnalisée de telle sorte que la taille totale des objets BoundedSource générés soit inférieure à cette limite de 20 Mo. Par exemple, votre source pourrait générer un nombre réduit de divisions initiales et s'appuyer sur le rééquilibrage dynamique du travail pour fractionner davantage les entrées à la demande.

Journaux des nœuds de calcul (Stackdriver)

"Traitement bloqué à l'étape <step_id> pendant au moins <time_interval> sans sortie ni fin à l'état terminé sur <stack_trace>"

Si Cloud Dataflow passe plus de temps à exécuter une opération DoFn que le temps spécifié dans <time_interval> sans retour, ce message est affiché.

Cette erreur a deux causes possibles :

  • Votre code DoFn est tout simplement lent, ou en attente d'une opération externe lente. Si tel est le cas, vous pouvez ignorer cet avertissement.
  • Votre code DoFn peut être bloqué ou anormalement lent pour terminer le traitement. Si vous pensez que c'est votre cas, développez l'entrée de journal Stackdriver pour afficher une trace de pile du code bloqué.

Vous pouvez approfondir les recherches sur la cause de blocage de votre code si votre pipeline s'appuie sur la VM Java (avec Java ou Scala). Effectuez un vidage de thread complet de la VM Java entière (pas seulement du thread bloqué) en procédant comme suit :

  1. Notez le nom du nœud de calcul à partir de l'entrée de journal.
  2. Dans la section Compute Engine de la console GCP, recherchez l'instance Compute Engine avec le nom de nœud de calcul que vous avez noté.
  3. Accédez via SSH à l'instance portant ce nom.
  4. Exécutez la commande suivante :

    curl http://localhost:8081/threadz
    

Exceptions de délai avant expiration de RPC, exceptions "DEADLINE_EXCEEDED" ou erreurs "Le serveur ne répond pas"

Si vous rencontrez des exceptions de dépassement du délai RPC, des exceptions DEADLINE_EXCEEDED ou des erreurs Server Unresponsive pendant l'exécution de votre tâche, il s'agit généralement de l'un des deux problèmes suivants :

  • Il manque une règle de pare-feu dans le réseau VPC utilisé pour votre tâche. Cette règle de pare-feu doit autoriser tout le trafic TCP entre les VM du réseau VPC que vous avez spécifié dans les options de pipeline. Pour plus de détails, consultez la page Spécifier votre réseau et votre sous-réseau.

  • Votre tâche est limitée en capacités de brassage. Appliquez l'une ou plusieurs des mesures correctives suivantes :

    Java : SDK 2.x

    • Ajoutez des nœuds de calcul. Essayez d'exécuter votre pipeline en spécifiant une valeur plus élevée pour le paramètre --numWorkers.
    • Augmentez la taille des disques associés aux nœuds de calcul. Essayez d'exécuter votre pipeline en spécifiant une valeur plus élevée pour le paramètre --diskSizeGb.
    • Utilisez un disque persistant SSD. Essayez d'exécuter votre pipeline en spécifiant le paramètre --workerDiskType="compute.googleapis.com/projects/<project>/zones/<zone>/diskTypes/pd-ssd".

    Python

    • Ajoutez des nœuds de calcul. Essayez d'exécuter votre pipeline en spécifiant une valeur plus élevée pour le paramètre --num_workers.
    • Augmentez la taille des disques associés aux nœuds de calcul. Essayez d'exécuter votre pipeline en spécifiant une valeur plus élevée pour le paramètre --disk_size_gb.
    • Utilisez un disque persistant SSD. Essayez d'exécuter votre pipeline en spécifiant le paramètre --worker_disk_type="compute.googleapis.com/projects/<project>/zones/<zone>/diskTypes/pd-ssd".

    Java : SDK 1.x

    • Ajoutez des nœuds de calcul. Essayez d'exécuter votre pipeline en spécifiant une valeur plus élevée pour le paramètre --numWorkers.
    • Augmentez la taille des disques associés aux nœuds de calcul. Essayez d'exécuter votre pipeline en spécifiant une valeur plus élevée pour le paramètre --diskSizeGb.
    • Utilisez un disque persistant SSD. Essayez d'exécuter votre pipeline en spécifiant le paramètre --workerDiskType="compute.googleapis.com/projects/<project>/zones/<zone>/diskTypes/pd-ssd".

Un appel provenant du faisceau du nœud de calcul Java vers une classe Python DoFn a échoué avec l'erreur <error message>

Si un objet DoFn implémenté dans Python échoue et génère une exception, le message d'erreur correspondant s'affiche.

Développez l'entrée du journal des erreurs Stackdriver, et examinez le message d'erreur et la trace. Vous découvrirez ainsi quelle ligne de code a échoué afin de la corriger si nécessaire. Si vous pensez qu'il s'agit d'un bug dans Apache Beam ou Cloud Dataflow, veuillez le signaler.

Aucun espace restant sur le dispositif

Si une tâche parcourt une grande quantité de données ou écrit des données temporaires sur des disques locaux, le stockage persistant du nœud de calcul risque de manquer d'espace.

Si vous obtenez un message vous prévenant qu'il ne reste plus d'espace sur le dispositif, augmentez la taille des disques persistants de vos nœuds de calcul en définissant l'option de pipeline appropriée. Pour les tâches Java, utilisez l'indicateur --diskSizeGb. Pour les tâches Python, utilisez --disk_size_gb.

Erreurs d'espace disque telles que "RESOURCE_EXHAUSTED : erreur d'E/S : aucun espace restant sur le disque"

Ces erreurs indiquent généralement que vous n'avez pas alloué suffisamment d'espace disque local pour traiter votre tâche. Si vous lancez une tâche avec les paramètres par défaut, celle-ci s'exécute sur 3 nœuds de calcul dotés de 250 Go d'espace disque local chacun sans autoscaling. Pensez à modifier les paramètres par défaut pour augmenter le nombre de nœuds de calcul disponibles pour votre tâche, pour augmenter la taille de disque par nœud de calcul par défaut ou pour activer l'autoscaling.

Avertissements "Requête incorrecte" dans les journaux du shuffler

Lors de l'exécution d'une tâche Cloud Dataflow, les journaux Stackdriver peuvent afficher une série d'avertissements semblables à ce qui suit :

Unable to update setup work item <step_id> error: generic::invalid_argument: Http(400) Bad Request
Update range task returned 'invalid argument'. Assuming lost lease for work with id <lease_id>
with expiration time: <timestamp>, now: <timestamp>. Full status: generic::invalid_argument: Http(400) Bad Request

Des avertissements "Requête incorrecte" apparaissent car les informations sur l'état du nœud de calcul sont obsolètes ou désynchronisées en raison de retards de traitement. Le plus souvent, votre tâche Cloud Dataflow réussit, malgré ces avertissements "Requête incorrecte". Si tel est le cas, ignorez les avertissements.

Cette page vous a-t-elle été utile ? Évaluez-la :

Envoyer des commentaires concernant…

Besoin d'aide ? Consultez notre page d'assistance.