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 Recurso: eventos bloqueados na fila de trabalho 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, a única ação que você pode usar com 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. É possível fazer isso configurando statusReason a maxTimeSeconds e CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY como 144000 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 EC2 instâncias da Amazon que apresentam erros de capacidade insuficientes. O cancelamento manual do trabalho permitirá que o trabalho subsequente seja movido para o início da fila, mas sem resolver os problemas de função de serviço, é provável que o próximo trabalho também seja bloqueado. É melhor investigar e resolver esse problema manualmente.

    • Mensagem 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 statusReason depois que o trabalho é cancelado: Canceled by JobStateTimeLimit action due to reason: CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY

    Observações:

    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) Permissões de função vinculadas ao serviço 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 EC2 computacional da Amazon anexado de alta prioridade apresentar insufficient capacity erros, ele bloqueará a fila mesmo que um ambiente computacional 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 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 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 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 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 perfil de serviço com o AWS políticas gerenciadas para AWS Batch e resolva as divergências. Observação: você não pode configurar uma ação programável por meio do jobStateTimeLimitActions parâmetro para resolver esse erro.

    É uma prática recomendada usar o Permissões de função vinculadas ao serviço 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 statusReason enquanto o trabalho está travado: MISCONFIGURATION:SERVICE_ROLE_PERMISSIONS – Batch service role has a permission issue.

  5. 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 statusReason enquanto o trabalho está travado: ACTION_REQUIRED - CE(s) associated with the job queue are invalid.

  6. 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 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 ecs-init pacote. 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 agente de contêiner do Amazon ECS for iniciado. Para ter 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 agente 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 Tutorial: criar uma VPC.

Limite de EC2 instâncias da Amazon atingido

O número de EC2 instâncias da Amazon em que sua conta pode iniciar Região da AWS é determinado pela sua cota de EC2 instâncias. Alguns tipos de instância também têm uma per-instance-type cota. Para obter mais informações sobre a cota de EC2 instância da Amazon da sua conta, incluindo como solicitar um aumento de limite, consulte Limites de EC2 serviços da Amazon no Guia do EC2 usuário da Amazon.

O agente do contêiner do Amazon ECS não está instalado

O agente de contêiner do Amazon ECS deve ser instalado na Amazon Machine Image (AMI) para permitir a AWS Batch execução de trabalhos. O agente de contêiner do Amazon ECS é instalado por padrão no Amazon ECS otimizado. AMIs Para obter mais informações sobre o agente de contêineres do Amazon ECS, consulte Agente de contêineres do Amazon ECS no Guia do desenvolvedor do Amazon Elastic Container Service.

Para obter mais informações, consulte Por que meu AWS Batch trabalho está preso no RUNNABLE status? em re:POST.