Causes courantes des jobs bloqués dans RUNNABLE sans StatusReason

Si vous n'avez pas reçu d'événement de la part d' CloudWatch Events ou si vous avez reçu un événement pour une raison inconnue, voici quelques causes courantes de ce problème.

Le pilote de awslogs journal n'est pas configuré sur vos ressources informatiques

AWS Batch les tâches envoient leurs informations de journal à CloudWatch Logs. Dans ce cas, vous devez configurer vos ressources de calcul de manière à ce qu'elles utilisent le pilote de journal awslogs. Supposons que vous basiez votre AMI de ressources de calcul sur l'AMI optimisée pour Amazon ECS (ou Amazon Linux). Ce pilote est ensuite enregistré par défaut dans le ecs-init package. Supposons maintenant que vous utilisiez une autre AMI de base. Vous devez ensuite vérifier que le pilote de awslogs journal est spécifié comme pilote de journal disponible avec la variable d'ECS_AVAILABLE_LOGGING_DRIVERSenvironnement lorsque l'agent de conteneur Amazon ECS est démarré. Pour plus d’informations, consultez Spécification de l'AMI des ressources de calcul et Tutoriel : Création d'une AMI de ressources de calcul.

Ressources insuffisantes

Si vos définitions de tâches spécifient plus de ressources de processeur ou de mémoire que ce que vos ressources de calcul peuvent allouer, vos tâches ne sont jamais placées. Supposons, par exemple, que votre tâche spécifie 4 GiB de mémoire et que vos ressources de calcul soient inférieures à celles disponibles. Il arrive alors que la tâche ne puisse pas être placée sur ces ressources informatiques. Dans ce cas, vous devez réduire la mémoire spécifiée dans la définition de tâche ou ajouter des ressources de calcul à votre environnement. Une partie de la mémoire est réservée à l'agent de conteneur Amazon ECS et à d'autres processus critiques du système. Pour de plus amples informations, veuillez consulter Gestion de la mémoire des ressources informatiques.

Pas d'accès à Internet pour les ressources informatiques

Les ressources de calcul ont besoin de communiquer avec le point de terminaison de service Amazon ECS service. Cela peut être via un point de terminaison d'un VPC d'interface ou via vos ressources de calcul ayant des adresses IP publiques.

Pour plus d'informations sur les points de terminaison d'un VPC d'interface, veuillez consulter Points de terminaison d'un VPC d'interface Amazon ECS AWS PrivateLink) dans le Guide du développeur Amazon Elastic Container Service.

Si vous n'avez pas de point de terminaison d'un VPC d'interface configuré et que vos ressources de calcul n'ont pas d'adresses IP publiques, elles doivent utiliser la traduction d'adresse réseau (NAT) pour fournir cet accès. Pour de plus amples informations, veuillez consulter Passerelles NAT dans le Guide de l'utilisateur Amazon VPC. Pour de plus amples informations, veuillez consulter Création d'un VPC.

Limite d'instances Amazon EC2 atteinte

Le nombre d'instances Amazon EC2 dans lesquelles votre compte peut être lancé Région AWS est déterminé par votre quota d'instances EC2. Certains types d'instances disposent également d'un quota par type d'instance. Pour plus d'informations sur le quota d'instances Amazon EC2 de votre compte, notamment sur la manière de demander une augmentation de limite, consultez les limites de service Amazon EC2 dans le guide de l'utilisateur Amazon EC2.

L'agent de conteneur Amazon ECS n'est pas installé

L'agent de conteneur Amazon ECS doit être installé sur l'Amazon Machine Image (AMI) pour permettre l' AWS Batch exécution de tâches. L'agent de conteneur Amazon ECS est installé par défaut sur les AMI optimisées Amazon ECS. Pour plus d'informations sur l'agent de conteneur Amazon ECS, consultez la section relative à l'agent de conteneur Amazon ECS dans le guide du développeur Amazon Elastic Container Service.

Long-running scripts de données utilisateur dans un modèle de lancement

Si votre modèle de lancement inclut un script de données utilisateur dont l'exécution prend du temps, les instances peuvent expirer avant leur enregistrement auprès d'Amazon ECS. Lorsque cela se produit, les instances ne sont jamais disponibles pour récupérer des tâches, toutes les tâches restent bloquées dans RUNNABLE leur statut. Tous les scripts de données utilisateur doivent être terminés avant qu'une instance puisse s'enregistrer auprès d'Amazon ECS et commencer à exécuter des tâches.

Pour résoudre ce problème, vérifiez les données utilisateur de votre modèle de lancement pour détecter les opérations de longue durée ou les opérations bloquantes. Envisagez d'optimiser les scripts pour réduire le temps d'exécution, d'exécuter des opérations non critiques de manière asynchrone ou de supprimer complètement la logique d'initialisation des données utilisateur. Pour de plus amples informations, veuillez consulter Utilisez les modèles de lancement Amazon EC2 avec AWS Batch.