本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 作业在`RUNNABLE`状态卡住
<a name="job_stuck_in_runnable"></a>

假设计算环境包含计算资源，但作业不会超出`RUNNABLE`状态。然后，很可能是某些因素阻止了将作业放置在计算资源上，并导致您的作业队列被阻止。以下介绍了如何了解您的作业是在等待轮候还是被卡住并阻止了队列。

如果 AWS Batch 检测到您的头部有`RUNNABLE`工作并封锁了队列，您将收到来自 Amazon E [作业队列阻塞事件](batch-job-queue-blocked-events.md) vents CloudWatch 的事件，其中包含原因。同样的原因也会更新到 `statusReason` 字段，作为 `[ListJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_ListJobs.html)` 和 `[DescribeJobs](https://docs.aws.amazon.com/batch/latest/APIReference/API_DescribeJobs.html)` API 调用的一部分。

或者，您可以通过 `[CreateJobQueue](https://docs.aws.amazon.com/batch/latest/APIReference/API_CreateJobQueue.html)` 和 [https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateJobQueue.html](https://docs.aws.amazon.com/batch/latest/APIReference/API_UpdateJobQueue.html) API 操作配置 `jobStateTimeLimitActions` 参数。

**注意**  
目前，对于连接到 Amazon ECS、Amazon EKS 或 Fargate 计算环境的任务队列，您可以使用的唯一操作`jobStateLimitActions.action`就是取消任务。

该`jobStateTimeLimitActions`参数用于指定对处于特定状态的作业 AWS Batch 执行的一组操作。您可以通过 `maxTimeSeconds` 字段设置以秒为单位的时间阈值。

当作业处于已定义的`RUNNABLE`状态时`statusReason`，将在经过后 AWS Batch `maxTimeSeconds`执行指定的操作。

例如，对于处于 `RUNNABLE` 状态等待足够容量可用的任何作业，您可以将 `jobStateTimeLimitActions` 参数设置为最多等待 4 小时。为此，您可以先将该任务设置`statusReason``maxTimeSeconds`为`CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY`和设置为 14400，然后再取消该任务并允许下一个作业进入任务队列的开头。

以下是它检测到作业队列被阻塞时 AWS Batch 提供的原因。此列表提供了从 `ListJobs` 和 `DescribeJobs` API 操作返回的消息。这些值也与您可以为 `jobStateLimitActions.statusReason` 参数定义的值相同。

1. **原因：**所有连接的计算环境都出现容量不足错误。在收到请求时， AWS Batch 会检测出现容量不足错误的 Amazon EC2 实例。手动取消任务将允许后续任务移至队列的开头。
   + **作业卡住时的 `statusReason` 消息：**`CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY - Service cannot fulfill the capacity requested for instance type [instanceTypeName]`
   + **用于 `jobStateTimeLimitActions` 的 `reason`：**`CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY`
   + **作业取消后的 `statusReason` 消息：**`Canceled by JobStateTimeLimit action due to reason: CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY`

   **注意：**

   1.  AWS Batch 服务角色需要`autoscaling:DescribeScalingActivities`权限才能使此检测生效。如果您使用 [将服务相关角色用于 AWS Batch](using-service-linked-roles.md) 服务相关角色（SLR）或 [AWS 托管策略:**AWSBatchServiceRole**策略](security-iam-awsmanpol.md#security-iam-awsmanpol-AWSBatchServiceRolePolicy) 托管式策略，则无需执行任何操作，因为其权限策略已更新。

   1. 如果您使用 SLR 或托管策略，则必须添加 `autoscaling:DescribeScalingActivities` 和 `ec2:DescribeSpotFleetRequestHistory` 权限，以便在处于 `RUNNABLE` 时可以接收已阻止的作业队列事件和更新的作业状态。此外， AWS Batch 需要这些权限才能通过 `jobStateTimeLimitActions` 参数执行 `cancellation` 操作，即使它们在作业队列中进行了配置。

   1. 对于多节点并行（MNP）作业，如果附加的高优先级 Amazon EC2 计算环境遇到 `insufficient capacity` 错误，即使优先级较低的计算环境确实遇到此错误，它也会阻止队列。

1. **原因：**所有计算环境都具有小于作业要求的 [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) 参数。手动或通过设置 `statusReason` 上的 `jobStateTimeLimitActions` 参数取消作业可以将后续作业移到队列的开头。或者，您可以增加主计算环境的 `maxvCpus` 参数以满足已阻止作业的需求。
   + **作业卡住时的 `statusReason` 消息：**`MISCONFIGURATION:COMPUTE_ENVIRONMENT_MAX_RESOURCE - CE(s) associated with the job queue cannot meet the CPU requirement of the job.`
   + **用于 `jobStateTimeLimitActions` 的 `reason`：**`MISCONFIGURATION:COMPUTE_ENVIRONMENT_MAX_RESOURCE`
   + **作业取消后的 `statusReason` 消息：**`Canceled by JobStateTimeLimit action due to reason: MISCONFIGURATION:COMPUTE_ENVIRONMENT_MAX_RESOURCE`

1. **原因：**所有计算环境都没有满足作业要求的实例。当任务请求资源时， AWS Batch 会检测到没有连接的计算环境能够容纳传入的作业。手动或通过设置 `statusReason` 上的 `jobStateTimeLimitActions` 参数取消作业可以将后续作业移到队列的开头。或者，您可以重新定义计算环境所允许的实例类型，以添加必要的作业资源。
   + **作业卡住时的 `statusReason` 消息：**` 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.`
   + **用于 `jobStateTimeLimitActions` 的 `reason`：**`MISCONFIGURATION:JOB_RESOURCE_REQUIREMENT`
   + **作业取消后的 `statusReason` 消息：**`Canceled by JobStateTimeLimit action due to reason: MISCONFIGURATION:JOB_RESOURCE_REQUIREMENT`

1. **原因：**所有计算环境都有服务角色问题。要解决此问题，请将您的服务角色权限与 [AWS 的托管策略 AWS Batch](security-iam-awsmanpol.md) 进行比较并设法解决任何差距。注意：此错误无法通过 `jobStateTimeLimitActions` 参数配置可编程操作来解决。

   最佳做法是使用 [将服务相关角色用于 AWS Batch](using-service-linked-roles.md) 来避免类似的错误。

   手动或通过设置 `statusReason` 上的 `jobStateTimeLimitActions` 参数取消作业可以将后续作业移到队列的开头。如果不解决服务角色问题，则下一个作业也可能被阻止。最好手动调查并解决此问题。
   + **作业卡住时的 `statusReason` 消息：**`MISCONFIGURATION:SERVICE_ROLE_PERMISSIONS – Batch service role has a permission issue.`

1.  **原因：**您的计算环境具有不受支持的实例类型配置。当实例类型在您选择的可用区中不可用，或者您的启动模板或启动配置包含与指定实例类型不兼容的设置时，即可能会出现此问题。要解决这个问题，请验证您的指定 AWS 区域 和可用区是否支持您的实例类型，检查您的启动模板设置是否与您的实例类型兼容，并考虑更新到新一代的实例类型。有关查找受支持实例类型的更多信息，请参阅《Amazon EC2 用户指南》中的[查找 Amazon EC2 实例类型](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-discovery.html)**。
   + **作业卡住时的 `statusReason` 消息：**`MISCONFIGURATION:EC2_INSTANCE_CONFIGURATION_UNSUPPORTED - Your compute environment associated with this job queue has an unsupported instance type configuration.`

1. **原因：**所有计算环境均无效。有关更多信息，请参阅 [`INVALID` 计算环境](invalid_compute_environment.md)。注意：您无法通过 `jobStateTimeLimitActions` 参数配置可编程操作来解决此错误。
   + **作业卡住时的 `statusReason` 消息：**`ACTION_REQUIRED - CE(s) associated with the job queue are invalid.`

1. **原因：** AWS Batch 已检测到队列被阻塞，但无法确定原因。注意：您无法通过 `jobStateTimeLimitActions` 参数配置可编程操作来解决此错误。有关故障排除的更多信息，请参阅 *re:Post* 中的[为什么我的 AWS Batch 作业在 AWS上卡在 RUNNABLE 状态](https://repost.aws/knowledge-center/batch-job-stuck-runnable-status)。
   + **作业卡住时的 `statusReason` 消息：**`UNDETERMINED - Batch job is blocked, root cause is undetermined.`

如果您没有收到来自事件 CloudWatch 的事件或收到未知原因事件，则以下是导致此问题的一些常见原因。

**计算资源上未配置 `awslogs` 日志驱动程序**  
AWS Batch 作业将其日志信息发送到 CloudWatch 日志。为了做到这一点，必须将计算资源配置为使用`awslogs`日志驱动程序。假设计算资源 AMI 基于 Amazon ECS 优化 AMI（或 Amazon Linux）。然后，该驱动程序默认会注册到`ecs-init`软件包中。假设现在使用的是不同的基础 AMI。然后，必须验证在启动 Amazon ECS 容器代理时，是否使用`ECS_AVAILABLE_LOGGING_DRIVERS`环境变量将`awslogs`日志驱动程序指定为可用的日志驱动程序。有关更多信息，请参阅[计算资源 &AMI; 规范](batch-ami-spec.md)和[教程：创建计算资源 AMI](create-batch-ami.md)：

**资源不足**  
如果作业定义指定的 CPU 或内存资源超出可分配的计算资源量，则作业将永远不会被放置。例如，假设作业指定了 4 GiB 的内存，而计算资源少于可用内存。那么，作业就不能放置在这些计算资源上。在这种情况下，必须减少作业定义中指定的内存，或者向环境中添加更大的计算资源。为 Amazon ECS 容器代理和其他关键系统进程保留了部分内存。有关更多信息，请参阅 [计算资源内存管理](memory-management.md)。

**无法通过互联网访问计算资源**  
计算资源需要访问才能与 Amazon ECS 服务端点通信。这可以通过接口 VPC 端点或具有公共 IP 地址的计算资源实现。  
有关接口 VPC 端点的更多信息，请参阅 *Amazon Elastic Container Service 开发人员指南*中的 [Amazon ECS 接口 VPC 端点(AWS PrivateLink)](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/vpc-endpoints.html)。  
如果没有配置接口 VPC 端点，并且计算资源没有公共 IP 地址，则必须使用网络地址转换 (NAT) 来提供这种访问。有关更多信息，请参阅*《Amazon VPC 用户指南》*中的。有关更多信息，请参阅 [创建 VPC](create-a-vpc.md)。

**已达到 Amazon EC2 实例限制**  
您的账户可以在中启动的 Amazon EC2 实例数量由您 AWS 区域 的 EC2 实例配额决定。某些实例类型也有配 per-instance-type额。有关账户的 Amazon EC2 实例配额（包括如何请求提高限制）的更多信息，请参阅《Amazon EC2 用户指南》**中的 [Amazon EC2 服务限制](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-resource-limits.html)。

**未安装 Amazon ECS 容器代理**  
必须将 Amazon ECS 容器代理安装在亚马逊机器映像（AMI）上才能使 AWS Batch 运行作业。默认情况下，Amazon ECS 容器代理安装在经过优化的亚马逊 ECS 上 AMIs。有关 Amazon ECS 容器代理的更多信息，请参阅*《Amazon Elastic Container Service 开发人员指南》*中的 [Amazon ECS 容器代理](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_agent.html)。

如需了解更多信息，请参阅[为什么我的 AWS Batch 工作`RUNNABLE`状态停滞不前？](https://aws.amazon.com/premiumsupport/knowledge-center/batch-job-stuck-runnable-status/) 在 re*: post* 中。