As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Causas comuns de trabalhos paralisados em RUNNABLE sem um StatusReason
Caso você não tenha recebido um evento da CloudWatch Events ou tenha recebido o evento de motivo desconhecido, aqui estão algumas causas comuns desse problema.
- O driver de log
awslogsnão está configurado em seus recursos de computação -
AWS Batch os jobs enviam suas informações de registro para o CloudWatch Logs. Para ativar, você deve configurar os recursos de computação para usar o driver de log
awslogs. Suponha que você baseie sua AMI de recursos de computação na AMI otimizada do Amazon ECS (ou Amazon Linux). Em seguida, esse driver é registrado por padrão com o pacoteecs-init. Agora, suponha que você use uma AMI base diferente. Em seguida, você deve verificar que o driver de logawslogsseja especificado como um driver de log disponível com a variável de ambienteECS_AVAILABLE_LOGGING_DRIVERSquando o atendente de contêiner do Amazon ECS for iniciado. Para obter mais informações, consulte Especificação da AMI do recurso de computação e Tutorial: criar uma AMI de recurso de computação. - Recursos insuficientes
-
Se suas definições de trabalho especificarem mais recursos de CPU ou memória do que seus recursos de computação podem alocar, seus trabalhos nunca serão colocados. Por exemplo, suponha que seu trabalho especifique 4 GiB de memória e que seus recursos de computação tenham menos do que os disponíveis. Então, acontece que o trabalho não pode ser colocado nesses recursos de computação. Nesse caso, você deve reduzir a memória especificada em sua definição de trabalho ou adicionar mais recursos de computação ao seu ambiente. Alguma memória é reservada para o atendente de contêiner do Amazon ECS e outros processos críticos do sistema. Para obter mais informações, consulte Gerenciamento de memória de recursos de computação.
- Sem acesso à Internet para os recursos de computação
Recursos de computação precisam de acesso para se comunicar com o endpoint de serviço do Amazon ECS. Isso pode ser feito por meio de uma interface do endpoint da VPC ou por meio dos das instâncias de contêiner que tenham endereços IP públicos.
Para obter mais informações sobre endpoints da VPC de interface, consulte Endpoints da VPC de interface do Amazon ECS (AWS PrivateLink) no Manual do Desenvolvedor do Amazon Elastic Container Service.
Se você não tiver um endpoint da VPC de interface configurado e seus das instâncias de contêiner não tiverem endereços IP públicos, eles deverão usar a conversão de endereço de rede (NAT) para fornecer esse acesso. Para obter mais informações, consulte Gateways NAT no Guia do usuário da Amazon VPC. Para obter mais informações, consulte Crie uma VPC.
- O limite de instâncias do Amazon EC2 foi atingido
-
O número de instâncias do Amazon EC2 em que sua conta pode iniciar Região da AWS é determinado pela cota de sua instância do EC2. Alguns tipos de instância também têm um limite de tipo por instância. Para obter mais informações sobre a cota de instância do Amazon EC2 da sua conta, incluindo como solicitar um aumento de limite, consulte Amazon EC2 Service Limits no Guia do usuário do Amazon EC2.
- O atendente do contêiner do Amazon ECS não está instalado
-
O atendente de contêiner do Amazon ECS deve ser instalado na imagem de máquina da Amazon (AMI) para permitir a execução de trabalhos do AWS Batch . O atendente do contêiner do Amazon ECS é instalado por padrão nas AMIs otimizadas para o Amazon ECS. Para obter mais informações sobre o atendente de contêineres do Amazon ECS, consulte Atendente de contêineres do Amazon ECS no Guia do desenvolvedor do Amazon Elastic Container Service.
- Long-running scripts de dados do usuário em um modelo de lançamento
-
Se o seu modelo de lançamento incluir um script de dados do usuário que leva muito tempo para ser concluído, as instâncias podem expirar antes de se registrarem no Amazon ECS. Quando isso acontece, as instâncias nunca ficam disponíveis para receber trabalhos, deixando todos os trabalhos presos no
RUNNABLEstatus. Todos os scripts de dados do usuário devem ser concluídos antes que uma instância possa se registrar no Amazon ECS e começar a executar trabalhos.Para resolver isso, revise os dados do usuário do modelo de lançamento para ver se há operações de longa duração ou de bloqueio. Considere otimizar scripts para reduzir o tempo de execução, executar operações não críticas de forma assíncrona ou remover totalmente a lógica de inicialização dos dados do usuário. Para obter mais informações, consulte Use os modelos de lançamento do Amazon EC2 com AWS Batch.
Para obter mais informações, consulte Por que meu AWS Batch trabalho está preso no RUNNABLE status?