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](batch-job-queue-blocked-events.md) evento da Amazon CloudWatch Events com o motivo. O mesmo motivo também é atualizado no campo `statusReason` como parte das chamadas de API `[ListJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_ListJobs.html)` e `[DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html)`. Opcionalmente, você pode configurar o parâmetro `jobStateTimeLimitActions` por meio das ações de API `[CreateJobQueue](https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateJobQueue.html)` e [https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateJobQueue.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateJobQueue.html). **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 definido`statusReason`, 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](using-service-linked-roles.md) ou a política gerenciada [AWS política gerenciada: **AWSBatchServiceRole**política](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSBatchServiceRolePolicy), não precisará tomar nenhuma medida, pois as políticas de permissão serão atualizadas. 1. 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. 1. 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. 1. **Motivo:** todos os ambientes de computação têm um parâmetro [https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResource.html#Batch-Type-ComputeResource-maxvCpus](https://docs.aws.amazon.com/batch/latest/APIReference/API_ComputeResource.html#Batch-Type-ComputeResource-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` 1. **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` 1. **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](security-iam-awsmanpol.md) e resolva as divergências. Observação: não é possível configurar uma ação programável por meio do parâmetro `jobStateTimeLimitActions` para solucionar esse erro. É uma prática recomendada usar o [Usando funções vinculadas a serviços para AWS Batch](using-service-linked-roles.md) 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.` 1. **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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-discovery.html) 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.` 1. **Motivo:** todos os ambientes de computação são inválidos. Para obter mais informações, consulte [Ambiente de computação do `INVALID`](invalid_compute_environment.md). 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.` 1. **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](https://repost.aws/knowledge-center/batch-job-stuck-runnable-status), 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](batch-ami-spec.md) e [Tutorial: criar uma AMI de recurso de computação](create-batch-ami.md). **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](memory-management.md). **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)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/vpc-endpoints.html) 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](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html) no *Guia do usuário da Amazon VPC*. Para obter mais informações, consulte [Crie uma VPC](create-a-vpc.md). **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 uma per-instance-type cota. 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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html) 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 agente de contêiner do Amazon ECS é instalado por padrão no Amazon ECS otimizado. AMIs Para obter mais informações sobre o atendente de contêineres do Amazon ECS, consulte [Atendente de contêineres do Amazon ECS ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_agent.html) 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?](https://aws.amazon.com/premiumsupport/knowledge-center/batch-job-stuck-runnable-status/) em *re:POST*.