View a markdown version of this page

Trabalhos presos no status RUNNABLE - AWS Batch

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

Trabalhos presos no status RUNNABLE

Suponha que seu ambiente de computação contenha recursos computacionais, mas seus trabalhos não progridam além do status RUNNABLE. Então, é provável que algo esteja impedindo que os trabalhos sejam colocados em um recurso de computação e fazendo com que suas filas de trabalho sejam bloqueadas. Veja como saber se o seu trabalho está aguardando a vez dele ou se está preso e bloqueando a fila.

Se AWS Batch detectar que você tem um RUNNABLE emprego como chefe e está bloqueando a fila, você receberá um Eventos bloqueados da fila de trabalhos evento da Amazon CloudWatch Events com o motivo. O mesmo motivo também é atualizado no campo statusReason como parte das chamadas de API ListJobs e DescribeJobs.

Opcionalmente, você pode configurar o parâmetro jobStateTimeLimitActions por meio das ações de API CreateJobQueue e UpdateJobQueue.

nota

Atualmente, para filas de trabalho conectadas aos ambientes computacionais Amazon ECS, Amazon EKS ou Fargate, a única ação que você pode usar jobStateLimitActions.action é cancelar um trabalho.

O jobStateTimeLimitActions parâmetro é usado para especificar um conjunto de ações que são AWS Batch executadas em trabalhos em um estado específico. É possível definir um limite de tempo em segundos por meio do campo maxTimeSeconds.

Quando um trabalho está em um RUNNABLE estado com o definidostatusReason, AWS Batch executa a ação especificada após maxTimeSeconds ter decorrido.

Por exemplo, você pode definir o parâmetro jobStateTimeLimitActions para aguardar até 4 horas por qualquer trabalho no estado RUNNABLE que esteja aguardando a disponibilidade de capacidade suficiente. Você pode fazer isso configurando statusReason para CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY e maxTimeSeconds para 14400 antes de cancelar o trabalho e permitir que o próximo trabalho avance para o início da fila de trabalhos.

A seguir estão os motivos que ocorrem AWS Batch quando ele detecta que uma fila de trabalhos está bloqueada. Esta lista fornece as mensagens retornadas das ações de API ListJobs e DescribeJobs. Também são os mesmos valores que podem ser definidos para o parâmetro jobStateLimitActions.statusReason.

  1. Motivo: todos os ambientes de computação conectados têm erros de capacidade insuficiente. Quando solicitado, AWS Batch detecta instâncias do Amazon EC2 que apresentam erros de capacidade insuficientes. O cancelamento manual do trabalho permitirá que o trabalho subsequente seja movido para o início da fila.

    • Mensagem do statusReason enquanto o trabalho está travado: CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY - Service cannot fulfill the capacity requested for instance type [instanceTypeName]

    • reason usado para jobStateTimeLimitActions: CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY

    • Mensagem do statusReason depois que o trabalho é cancelado: Canceled by JobStateTimeLimit action due to reason: CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY

    Observação:

    1. A função AWS Batch de serviço requer autoscaling:DescribeScalingActivities permissão para que essa detecção funcione. Se você usar o perfil vinculado a serviço (SLR) Usando funções vinculadas a serviços para AWS Batch ou a política gerenciada AWS política gerenciada: AWSBatchServiceRolepolítica, não precisará tomar nenhuma medida, pois as políticas de permissão serão atualizadas.

    2. Se você usar a SLR ou a política gerenciada, deverá adicionar as permissões autoscaling:DescribeScalingActivities e ec2:DescribeSpotFleetRequestHistory para poder receber eventos de fila de trabalho bloqueada e status de trabalho atualizado quando estiver em RUNNABLE. Além disso, o AWS Batch precisa dessas permissões para executar ações do cancellation por meio do parâmetro jobStateTimeLimitActions, mesmo que elas estejam configuradas na fila de trabalho.

    3. No caso de um trabalho paralelo de vários nós (MNP), se o ambiente de computação do Amazon EC2 de alta prioridade anexado apresentar erros de insufficient capacity, ele bloqueará a fila mesmo que um ambiente de computação de prioridade mais baixa apresente esse erro.

  2. Motivo: todos os ambientes de computação têm um parâmetro maxvCpus menor do que os requisitos do trabalho. O cancelamento do trabalho, seja manualmente ou definindo o parâmetro jobStateTimeLimitActions em statusReason, permite que o trabalho subsequente seja movido para o topo da fila. Como opção, é possível aumentar o parâmetro maxvCpus do ambiente de computação primário para atender às necessidades do trabalho bloqueado.

    • Mensagem do statusReason enquanto o trabalho está travado: MISCONFIGURATION:COMPUTE_ENVIRONMENT_MAX_RESOURCE - CE(s) associated with the job queue cannot meet the CPU requirement of the job.

    • reason usado para jobStateTimeLimitActions: MISCONFIGURATION:COMPUTE_ENVIRONMENT_MAX_RESOURCE

    • Mensagem do statusReason depois que o trabalho é cancelado: Canceled by JobStateTimeLimit action due to reason: MISCONFIGURATION:COMPUTE_ENVIRONMENT_MAX_RESOURCE

  3. Motivo: nenhum dos ambientes de computação tem instâncias que atendem aos requisitos do trabalho. Quando um trabalho solicita recursos, AWS Batch detecta que nenhum ambiente computacional conectado é capaz de acomodar o trabalho recebido. O cancelamento do trabalho, seja manualmente ou definindo o parâmetro jobStateTimeLimitActions em statusReason, permite que o trabalho subsequente seja movido para o topo da fila. Como opção, é possível redefinir os tipos de instância permitidos do ambiente de computação para adicionar os recursos de trabalho necessários.

    • Mensagem do statusReason enquanto o trabalho está travado: MISCONFIGURATION:JOB_RESOURCE_REQUIREMENT - The job resource requirement (vCPU/memory/GPU) is higher than that can be met by the CE(s) attached to the job queue.

    • reason usado para jobStateTimeLimitActions: MISCONFIGURATION:JOB_RESOURCE_REQUIREMENT

    • Mensagem do statusReason depois que o trabalho é cancelado: Canceled by JobStateTimeLimit action due to reason: MISCONFIGURATION:JOB_RESOURCE_REQUIREMENT

  4. Motivo: todos os ambientes de computação têm problemas de perfil de serviço. Para resolver isso, compare suas permissões de função de serviço com a AWS políticas gerenciadas para AWS Batch e resolva quaisquer lacunas. Note:You não é possível configurar uma ação programável por meio do jobStateTimeLimitActions parâmetro para resolver esse erro.

    É uma prática recomendada usar o Usando funções vinculadas a serviços para AWS Batch para evitar erros semelhantes.

    O cancelamento do trabalho, seja manualmente ou definindo o parâmetro jobStateTimeLimitActions em statusReason, permite que o trabalho subsequente seja movido para o topo da fila. Sem resolver o(s) problema(s) do perfil de serviço, é provável que o próximo trabalho também seja bloqueado. É melhor investigar e resolver esse problema manualmente.

    • Mensagem do statusReason enquanto o trabalho está travado: MISCONFIGURATION:SERVICE_ROLE_PERMISSIONS – Batch service role has a permission issue.

  5. Motivo: seu ambiente computacional tem uma configuração de tipo de instância incompatível. Isso pode ocorrer quando os tipos de instância não estão disponíveis nas zonas de disponibilidade selecionadas ou quando seu modelo de execução ou configuração de execução contém configurações incompatíveis com os tipos de instância especificados. Para resolver isso, verifique se seus tipos de instância são compatíveis com suas zonas especificadas Região da AWS e de disponibilidade, verifique se as configurações do modelo de execução são compatíveis com seus tipos de instância e considere atualizar para tipos de instância de geração mais recente. Para obter mais informações sobre como encontrar tipos de instância compatíveis, consulte Como encontrar um tipo de instância do Amazon EC2 no Guia do usuário do Amazon EC2.

    • Mensagem do statusReason enquanto o trabalho está travado: MISCONFIGURATION:EC2_INSTANCE_CONFIGURATION_UNSUPPORTED - Your compute environment associated with this job queue has an unsupported instance type configuration.

  6. Motivo: todos os ambientes de computação são inválidos. Para obter mais informações, consulte Ambiente de computação do INVALID. Observação: não é possível configurar uma ação programável por meio do parâmetro jobStateTimeLimitActions para solucionar esse erro.

    • Mensagem do statusReason enquanto o trabalho está travado: ACTION_REQUIRED - CE(s) associated with the job queue are invalid.

  7. Motivo: AWS Batch detectou uma fila bloqueada, mas não consegue determinar o motivo. Observação: não é possível configurar uma ação programável por meio do parâmetro jobStateTimeLimitActions para solucionar esse erro. Para obter mais informações sobre a solução de problemas, consulte Por que meu trabalho do AWS Batch está preso em RUNNABLE na AWS, no re:Post.

    • Mensagem do statusReason enquanto o trabalho está travado: UNDETERMINED - Batch job is blocked, root cause is undetermined.

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 awslogs nã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 pacote ecs-init. Agora, suponha que você use uma AMI base diferente. Em seguida, você deve verificar que o driver de log awslogs seja especificado como um driver de log disponível com a variável de ambiente ECS_AVAILABLE_LOGGING_DRIVERS quando 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 RUNNABLE status. 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? em re:POST.