本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# 任務停滯在 `RUNNABLE` 狀態
<a name="job_stuck_in_runnable"></a>

假設您的運算環境包含運算資源，但您的任務不會超過 `RUNNABLE` 狀態。然後，某件事可能會阻止任務放置在運算資源上，並導致您的任務佇列遭到封鎖。以下是如何知道您的任務正在等待輪換或卡住並封鎖佇列的方法。

如果 AWS Batch 偵測到您有一個前端`RUNNABLE`任務並封鎖佇列，您會收到來自 Amazon CloudWatch Events [任務佇列封鎖事件](batch-job-queue-blocked-events.md)的事件，其中包含原因。相同的原因也會更新為 `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` 經過之後指定的動作。

例如，您可以設定 `jobStateTimeLimitActions` 參數，為 `RUNNABLE` 狀態中等待足夠容量的任何任務等待最多 4 小時。您可以在取消任務之前`statusReason`將 設定為 `CAPACITY:INSUFFICIENT_INSTANCE_CAPACITY`，並將 `maxTimeSeconds`設定為 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]`
   + **`reason` 用於 `jobStateTimeLimitActions`：** `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)參數都小於任務需求。在 上手動或透過設定 `jobStateTimeLimitActions` 參數來取消任務`statusReason`，可讓後續任務移至佇列的前端。或者，您可以增加主要運算環境的 `maxvCpus` 參數，以滿足封鎖任務的需求。
   + **`statusReason` 當任務停滯時的訊息：** `MISCONFIGURATION:COMPUTE_ENVIRONMENT_MAX_RESOURCE - CE(s) associated with the job queue cannot meet the CPU requirement of the job.`
   + **`reason` 用於 `jobStateTimeLimitActions`：** `MISCONFIGURATION:COMPUTE_ENVIRONMENT_MAX_RESOURCE`
   + **`statusReason` 任務取消後的訊息：** `Canceled by JobStateTimeLimit action due to reason: MISCONFIGURATION:COMPUTE_ENVIRONMENT_MAX_RESOURCE`

1. **原因：**沒有任何運算環境的執行個體符合任務需求。當任務請求資源時， 會 AWS Batch 偵測沒有連接的運算環境能夠容納傳入的任務。在 上手動或透過設定 `jobStateTimeLimitActions` 參數來取消任務`statusReason`，可讓後續任務移至佇列的前端。或者，您可以重新定義運算環境允許的執行個體類型，以新增必要的任務資源。
   + **`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.`
   + **`reason` 用於 `jobStateTimeLimitActions`：** `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)來避免類似的錯誤。

   在 上手動或透過設定 `jobStateTimeLimitActions` 參數來取消任務`statusReason`，可讓後續任務移至佇列的前端。如果沒有解決服務角色問題 （服務角色），則可能也會封鎖下一個任務。最好手動調查並解決此問題。
   + **`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)。 *Amazon EC2 *
   + **`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 任務卡在 RUNNABLE AWS](https://repost.aws/knowledge-center/batch-job-stuck-runnable-status)中。
   + **`statusReason` 任務停滯時的 訊息：** `UNDETERMINED - Batch job is blocked, root cause is undetermined.`

如果您未從 CloudWatch Events 收到事件，或收到不明原因事件，以下是一些常見的此問題原因。

**未在運算資源上設定`awslogs`日誌驅動程式**  
AWS Batch 任務會將日誌資訊傳送至 CloudWatch Logs。若要啟用此功能，您必須設定運算資源使用 `awslogs` 日誌驅動程式。假設您根據 Amazon ECS 最佳化 AMI （或 Amazon Linux) 建立運算資源 AMI 的基礎。然後，此驅動程式預設會向 `ecs-init`套件註冊。現在假設您使用不同的基本 AMI。然後，您必須驗證在 Amazon ECS 容器代理程式啟動時，`awslogs`日誌驅動程式已指定為具有 `ECS_AVAILABLE_LOGGING_DRIVERS`環境變數的可用日誌驅動程式。如需詳細資訊，請參閱[運算資源 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 使用者指南*中的 [NAT 閘道](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)。如需詳細資訊，請參閱[建立 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 EC2 *

**未安裝 Amazon ECS 容器代理程式**  
Amazon ECS 容器代理程式必須安裝在 Amazon Machine Image (AMI) 上，才能讓 AWS Batch 執行任務。根據預設，Amazon ECS 容器代理程式會安裝在 Amazon ECS 最佳化 AMIs上。如需 Amazon ECS 容器代理程式的詳細資訊，請參閱《[Amazon Elastic Container Service 開發人員指南》中的 Amazon ECS 容器代理](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ECS_agent.html)程式。 **

**啟動範本中長時間執行的使用者資料指令碼**  
如果您的啟動範本包含需要很長時間才能完成的使用者資料指令碼，執行個體可能會在向 Amazon ECS 註冊之前逾時。發生這種情況時，執行個體永遠無法用於接收任務，讓所有任務停滯在 `RUNNABLE` 狀態。所有使用者資料指令碼都必須完成，執行個體才能向 Amazon ECS 註冊並開始執行任務。  
若要解決此問題，請檢閱啟動範本使用者資料是否有長時間執行或封鎖的操作。考慮最佳化指令碼以縮短執行時間、非同步執行非關鍵操作，或將初始化邏輯完全移出使用者資料。如需詳細資訊，請參閱[搭配 使用 Amazon EC2 啟動範本 AWS Batch](launch-templates.md)。

如需詳細資訊，請參閱[為什麼我的 AWS Batch 任務卡在 `RUNNABLE` 狀態？](https://aws.amazon.com/premiumsupport/knowledge-center/batch-job-stuck-runnable-status/) *re：Post* 中的 。