Pourquoi ma tâche AWS Glue échoue-t-elle avec l'erreur « Exit status: -100. Diagnostics: Container released on a *lost* node » (Statut de sortie : -100. Diagnostic : conteneur lancé sur un nœud *perdu*) dans AWS Glue ?

Date de la dernière mise à jour : 21/11/2019

Ma tâche AWS Glue a échoué avec l'erreur suivante : « Exit status: -100. Diagnostics: Container released on a *lost* node » (Statut de sortie : -100. Diagnostic : conteneur lancé sur un nœud *perdu*) dans AWS Glue.

Résolution

Si JDBC est votre source de données, consultez Ma tâche AWS Glue échoue avec une perte de nœuds lors de la migration d'un ensemble de données volumineux d'Amazon RDS vers Amazon S3. Si votre source de données est Amazon Simple Storage Service (Amazon S3), utilisez une ou plusieurs des méthodes suivantes pour résoudre les erreurs de nœud perdus.

Ajouter d'autres DPU

Par défaut, les tâches AWS Glue ont 10 DPU et utilisent le type de travail Standard. Un DPU est réservé pour le maître d'application. Prenez en compte les éléments suivants avant d'ajouter d'autres DPU :

  • L'ajout de DPU supplémentaires n'est utile que si la charge de travail de la tâche est mise en parallèle. Si vous ne partitionnez pas les données de manière appropriée, elles ne seront pas distribuées aux nouveaux nœuds et vous recevrez des erreurs de nœud perdues. Pour plus d'informations, consultez Déterminer la capacité DPU optimale.
  • Dans certains cas, les fichiers volumineux peuvent consommer trop de ressources sur un nœud, ce qui réduit l'efficacité de la mise en parallèle de la charge de travail de la tâche. Pour atténuer ce problème, assurez-vous que les fichiers volumineux sont dans un format fractionnable. Pour plus d'informations, consultez Bonnes pratiques pour dimensionner les tâches Apache Spark et partitionner les données avec AWS Glue.
  • Plus une tâche s'exécute longtemps, plus la tâche écrit sur le disque. Si les journaux sont à l'origine du problème d'espace disque, l'ajout de DPU supplémentaires ne sera d'aucune aide. Dans certains cas, les erreurs de nœud perdues sont provoquées à la fois par une journalisation excessive et des débordements de disque.
  • Vérifiez les journaux et lamétrique glue.ALL.jvm.heap.usage d'Amazon CloudWatch pour identifier les programmes d'exécution qui consomment de l'espace mémoire. Si certains programmes d'exécution consomment plus d'espace mémoire que d'autres, l'asymétrie des données peut être à l'origine de l'erreur.

Utilisez l'API des tâches, l'interface de ligne de commande AWS (AWS CLI) ou la console AWS Glue pour ajouter d'autres DPU lorsque vous créez une tâche :

  • API des tâches : définissez la propriété NumberOfWorkers lorsque vous exécutez l'opération CreateJob.
  • Interface de ligne de commande AWS : définissez la propriété number-of-workers lorsque vous exécutez la commande create-job.
  • Console AWS Glue : sur la page « Configure the job properties » (Configurer les propriétés de tâches) sous « Security configuration, script libraries and job parameters (optional) » (Configuration de la sécurité, bibliothèques de scripts et paramètres de tâches (en option)), augmentez la valeur de « Maximum capacity » (Capacité maximale). Il s'agit du nombre de DPU pour la tâche.

Assurez-vous que les métriques CloudWatch sont activées pour la tâche. Ces métriques peuvent vous aider à surveiller les performances des tâches et à déterminer si vous avez besoin d'ajouter d'autres DPU. Utilisez l'API des tâches, l'AWS CLI ou la console AWS Glue pour activer les métriques pour une tâche nouvelle ou existante :

  • API des tâches : utilisez l'argument -enable-metrics lorsque vous définissez DefaultArguments dans les opérations CreateJob ou UpdateJob.
  • Interface de ligne de commande AWS : utilisez l'argument -enable-metrics.
  • Console AWS Glue : sous « Monitoring options » (Options de surveillance), définissez « Job metrics » (Métriques de tâche) sur « Enabled » (Activé).

Modifier le type de travail du DPU

En fonction de la taille de votre ensemble de données, le type de travail Standard peut ne pas avoir suffisamment de ressources pour empêcher l'application Spark de manquer de mémoire et de déborder sur le disque. Pour résoudre ce problème, choisissez un type de travail avec plus de ressources disponibles :

  • Standard (par défaut) : chaque application de travail est mappée sur 1 DPU (4 vCPU, 16 Go de mémoire) et dispose de 50 Go d'espace disque.
  • G.1X : chaque application de travail est mappée sur 1 DPU (4 vCPU, 16 Go de mémoire) et dispose de 64 Go d'espace disque.
  • G.2X : chaque application de travail est mappée sur 2 processeurs (8 vCPU, 32 Go de mémoire) et dispose de 128 Go d'espace disque.

Utilisez l'API des tâches, l'AWS CLI ou la console AWS Glue pour modifier le type de travail lorsque vous créez une tâche :

  • API des tâches : définissez la propriété WorkerType lorsque vous exécutez l'opération CreateJob.
  • Interface de ligne de commande AWS (AWS CLI) : définissez la propriété worker-type lorsque vous exécutez la commande create-job.
  • Console AWS Glue : sur la page « Configure the job properties » (Configuer les propriétés de tâches) sous « Security configuration, script libraries and job parameters (optional) » ((Configuration de la sécurité, bibliothèques de scripts et paramètres de tâches (en option)), choisissez une autre option pour « Worker type » (Type de travail).

Cet article vous a-t-il été utile ?

Cette page peut-elle être améliorée ?


Vous avez besoin d'aide ?