作业在RUNNABLE状态卡住 - AWS Batch

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

作业在RUNNABLE状态卡住

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

如果 AWS Batch 检测到您的头部有RUNNABLE工作并封锁了队列，您将收到来自 Amazon E 资源：作业队列已阻止事件 vents CloudWatch 的事件，其中包含原因。同样的原因也会更新到 statusReason 字段，作为 ListJobs 和 DescribeJobs API 调用的一部分。

或者，您可以通过 CreateJobQueue 和 UpdateJobQueue API 操作配置 jobStateTimeLimitActions 参数。

注意

目前，您可以用于 jobStateLimitActions.action 的唯一操作是取消作业。

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

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

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

以下是它检测到作业队列被阻塞时 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 服务相关角色（SLR）或 AWS 托管策略:AWSBatchServiceRole策略 托管策略，则无需采取任何操作，因为他们的权限策略已更新。

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

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

  2. 原因：所有计算环境都具有小于作业要求的 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

  3. 原因：所有计算环境都没有满足作业要求的实例。当任务请求资源时， 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

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

    最佳做法是使用 的服务相关角色权限 AWS Batch 来避免类似的错误。

    手动或通过设置 statusReason 上的 jobStateTimeLimitActions 参数取消作业可以将后续作业移到队列的开头。如果不解决服务角色问题，则下一个作业也可能被阻止。最好手动调查并解决此问题。

    • 作业卡住时的 statusReason 消息：MISCONFIGURATION:SERVICE_ROLE_PERMISSIONS – Batch service role has a permission issue.

  5. 原因：所有计算环境均无效。有关更多信息，请参阅 INVALID 计算环境。注意：您无法通过 jobStateTimeLimitActions 参数配置可编程操作来解决此错误。

    • 作业卡住时的 statusReason 消息：ACTION_REQUIRED - CE(s) associated with the job queue are invalid.

  6. 原因： AWS Batch 已检测到队列被阻塞，但无法确定原因。注意：您无法通过 jobStateTimeLimitActions 参数配置可编程操作来解决此错误。有关故障排除的更多信息，请参阅 re:Post 中的为什么我的 AWS Batch 作业在 AWS上卡在 RUNNABLE 状态。

    • 作业卡住时的 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; 规范和教程：创建计算资源 AMI：

资源不足

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

无法通过互联网访问计算资源

计算资源需要访问才能与 Amazon ECS 服务端点通信。这可以通过接口 VPC 端点或具有公共 IP 地址的计算资源实现。

有关接口 VPC 端点的更多信息，请参阅 Amazon Elastic Container Service 开发人员指南中的 Amazon ECS 接口 VPC 端点(AWS PrivateLink)。

如果没有配置接口 VPC 端点，并且计算资源没有公共 IP 地址，则必须使用网络地址转换 (NAT) 来提供这种访问。有关更多信息，请参阅《Amazon VPC 用户指南》中的。有关更多信息，请参阅 教程：创建 VPC。

已达到亚马逊 EC2 实例上限

您的账户可以在中启动的 Amazon EC2 实例数量取决于您的 EC2 实例配额。 AWS 区域 某些实例类型也有配 per-instance-type额。有关您账户的亚马逊 EC2 实例配额的更多信息，包括如何申请提高限额，请参阅亚马逊 EC2 用户指南中的亚马逊 EC2服务限制。

未安装 Amazon ECS 容器代理

必须将 Amazon ECS 容器代理安装在亚马逊机器映像（AMI）上才能使 AWS Batch 运行作业。默认情况下，Amazon ECS 容器代理安装在经过优化的亚马逊 ECS 上 AMIs。有关 Amazon ECS 容器代理的更多信息，请参阅《Amazon Elastic Container Service 开发人员指南》中的 Amazon ECS 容器代理。

如需了解更多信息，请参阅为什么我的 AWS Batch 工作RUNNABLE状态停滞不前？ 在 re: post 中。