執行失敗原因

如果執行失敗，請使用 GetRun API 操作來擷取失敗原因。

檢閱失敗原因，以協助您疑難排解執行失敗的原因。下表列出每個失敗原因以及錯誤的說明。

故障原因	錯誤說明
ASSUME_ROLE_FAILED	HealthOmics 沒有擔任該角色的許可。在角色的信任關係中指定 HealthOmics 委託人。
CANNOT_START_CONTAINER_ERROR	無法啟動工作流程任務：名稱、ID：使用映像的 ID 容器：映像名稱。請確定映像有效，然後再試一次。
CANNOT_START_CONTAINER_SIZE_ERROR	無法啟動工作流程任務：名稱、ID：使用映像的 ID 容器：映像名稱。請確定映像大小小於 45 GiB (GPU 執行個體為 95 GiB)，然後再試一次。
ECR_PERMISSION_ERROR	HealthOmics 沒有存取映像 URI 的許可。 確認 Amazon ECR 私有儲存庫存在，並已授予 HealthOmics 服務主體的存取權。
EXPORT_FAILED	匯出失敗。檢查輸出儲存貯體是否存在，且執行角色具有對儲存貯體的寫入許可。
FILE_SYSTEM_OUT_OF_SPACE	檔案系統沒有足夠的空間。增加檔案系統大小並再次執行。
IMAGE_VERIFICATION_FAILURE	無法驗證映像名稱。若要修正此問題，請嘗試提取映像，然後再次將其推送到您的 ECR 儲存庫。
IMPORT_FAILED	匯入失敗。檢查輸入檔案是否存在，且執行角色可以存取輸入。
INACTIVE_OMICS_STORAGE_RESOURCE	HealthOmics 儲存 URI 未處於 ACTIVE 狀態。啟用讀取集，然後再試一次。若要進一步了解啟用讀取集，請參閱 在 HealthOmics 中啟用讀取集。
INPUT_URI_NOT_FOUND	提供的 URI 不存在：uri。檢查 URI 路徑是否存在，並確認角色可以存取物件。
INSTANCE_RESERVATION_FAILED	沒有足夠的執行個體容量來完成工作流程執行。等待並再次嘗試工作流程執行。若要進一步了解執行個體保留失敗的錯誤緩解，請參閱 緩解 INSTANCE_RESERVATION_FAILED 錯誤。
INVALID_ECR_IMAGE_URI	Amazon ECR 映像 URI 結構無效。請提供有效的 URI，然後再試一次。
INVALID_TASK_RESOURCE_VALUE	請求的 GPU、CPU 或記憶體對於可用的運算容量過高，或小於任務 ID 的最小值 1。
INVALID_URI_INPUT	URI 結構不是有效的 uri。請檢查 URI 結構，然後再試一次。
MODIFIED_INPUT_RESOURCE	提供的 URI uri 已在執行開始後修改。重試執行。
OUT_OF_MEMORY_ERROR	工作流程任務 ID 記憶體不足。增加工作流程定義中的記憶體值，然後再次嘗試執行。
RUN_TASK_FAILED	執行失敗，因為任務失敗。若要偵錯任務失敗，請使用 GetRunTask API 操作和 Amazon CloudWatch Logs 串流。
RUN_TIMED_OUT	在幾分鐘後執行逾時。
SERVICE_ERROR	服務中發生暫時性錯誤。再次嘗試工作流程執行。
TASK_TIMED_OUT	任務 ID 在數秒後逾時。
UNSUPPORTED_INPUT_SIZE	總輸入大小太高。減少輸入大小，然後再試一次。
WORKFLOW_RUN_FAILED	工作流程執行失敗。檢閱 CloudWatch Logs 引擎日誌串流：用於偵錯失敗的 ID。
WORKFLOW_VER_VALIDATION_FAILED	HealthOmics 不支援請求的 Nextflow 版本：版本 --。最新支援的版本是 版本。將您的 Nextflow 版本修改為支援的版本，然後再試一次。
UNSUPPORTED_GPU_INSTANCE_TYPE	區域不支援請求的執行個體類型。使用此區域支援的 GPU 執行個體類型重試執行。可用的執行個體類型為 GPU 執行個體類型。

緩解 INSTANCE_RESERVATION_FAILED 錯誤

GPU 執行個體是隨需資源，不一定會在您偏好的可用區域或區域中立即可用。

HealthOmics 會自動執行的操作

HealthOmics 會代表您執行數個最佳化，以最大化 GPU 取得成功：

• 多可用區域搜尋：HealthOmics 會檢查多個可用區域是否有 GPU 容量，而不只是單一可用區域。

• 自動重試：當 GPU 無法立即使用時，HealthOmics 會多次重試以取得可用容量。

• 跨任務的 GPU 保留：當您的工作流程具有需要 GPU 的循序任務時，HealthOmics 會保留您在後續任務中已有的 GPU，而不是將其釋放並重新請求，以確保成功完成多步驟 GPU 工作流程。

下列其他最佳實務可進一步改善您在 HealthOmics 上執行 GPU 加速工作流程時的成功率：

1. 使用加速器套件來最大化彈性

   使用加速器套件來允許 HealthOmics 從多個相容的 GPU 世代 （例如 g4dn、g5、g6) 選取，而不是請求特定的 GPU 執行個體類型。工作流程可以接受的 GPU 類型越多，尋找可用容量的機率就越高。

   如需詳細資訊，請參閱 HealthOmics 工作流程定義中的任務加速器。例如：

   • nvidia-t4-a10g-l4 取自 G4、G5 和 G6 執行個體系列

   • nvidia-l4-a10g 取自 G5 和 G6 執行個體系列

2. 考慮在其他 AWS 區域中執行您的工作流程

   GPU 可用性因 AWS 區域而異。如果您的資料駐留需求允許，請考慮在容量可能更容易取得的不同區域中執行 GPU 密集型工作流程。若要進一步了解支援的 區域，請參閱 的服務配額和端點 AWS HealthOmics。

3. 設定資源備用 （僅限 WDL 工作流程）

   對於 WDL 工作流程， omicsResourceFallbackOrder指令可讓您定義每個任務的資源設定檔 (GPU 或 CPU) 的排序清單。如果您偏好的加速器類型無法使用，HealthOmics 會自動嘗試下一個加速器類型或 CPU，而不是失敗。您也可以指定 HealthOmics 應搜尋 GPU 的時間長度。使用案例包括：

   • GPU 轉 GPU 備用 – 請先試用您偏好的加速器，然後返回替代 （例如，nvidia-l40s先試，再試 nvidia-l4)。

   • GPU 到 CPU 備用 – 新增僅限 CPU 的最終設定檔，即使沒有 GPU 容量，任務也會完成。

   注意

   omicsResourceFallbackOrder 指令目前僅支援 WDL 工作流程。已規劃 Nextflow 支援。

   如需詳細資訊，請參閱 進階資源組態。

無回應執行的指引

開發新的工作流程時，如果程式碼發生問題，執行或特定任務可能會變成「停滯」或「停止」，而且任務無法正常結束程序。這對於故障診斷和捕捉可能具有挑戰性，因為任務長時間執行是正常的。若要防止和識別無回應的執行，請遵循以下章節中建議的最佳實務。

防止無回應執行的最佳實務

• 請確定您正在關閉任務程式碼中開啟的所有檔案。開啟太多檔案偶爾會導致工作流程引擎中的執行緒問題。

• 工作流程任務建立的背景程序應在任務結束時結束。不過，如果背景程序無法順利結束，您必須在任務程式碼中明確關閉該程序。

• 確保您的程序不會在沒有結束的情況下循環。這可能會導致無回應的執行，並且需要變更工作流程定義程式碼才能解決。

• 為您的任務提供適當的記憶體和 CPU 配置。分析 CloudWatch 日誌或在成功完成的工作流程執行執行分析器時使用 ，以確認您擁有最佳的運算配置。使用 Run Analyzer headroom 參數來包含額外的空間，確保程序有足夠的資源可完成。在配置的記憶體和 CPU 中包含至少 5% 的預留空間，以考慮背景作業系統程序。

  • 此外，如果執行個體需要更高的輸送量，請增加執行個體頻寬大小。少於 16 個 vCPUs Amazon EC2 執行個體可能會發生輸送量暴增。如需 Amazon EC2 執行個體輸送量的詳細資訊，請參閱 Amazon EC2 可用的執行個體頻寬。

• 請確定您使用正確的檔案系統大小來執行 。對於使用靜態執行儲存的無回應執行，請考慮增加靜態執行儲存配置，以在檔案系統上啟用更高的 IO 輸送量和儲存容量。分析執行資訊清單以查看最大檔案系統儲存，使用 Run Analyzer 判斷是否需要增加檔案系統配置。

擷取無回應執行的最佳實務

• 開發新的工作流程時，請使用已設定執行時間上限的執行群組，以擷取失控程式碼。例如，如果執行需要 1 小時才能完成，請將其放在 2 或 3 小時 （或根據您的使用案例的不同時段） 後逾時的執行群組中，以擷取失控任務。此外，套用緩衝區以考量處理時間的差異。

• 設定一系列具有不同最大執行時間限制的執行群組。例如，您可以將短執行指派給在幾小時後終止執行的執行群組，以及根據預期的工作流程持續時間，在幾天後終止執行的長執行群組。

• HealthOmics 的預設執行持續時間服務限制上限為 604，800 秒或 7 天，可透過配額工具中的請求進行調整。只有在您有接近一週持續時間的執行時，才請求提高此配額的服務限制。如果您有短執行和長執行的混合，且未使用執行群組，請考慮將長時間執行的執行放在具有較高執行持續時間服務限制上限的個別帳戶中。

• 檢查 CloudWatch 日誌是否有您懷疑可能沒有回應的任務。如果任務通常會輸出一般日誌陳述式，並且長時間沒有這樣做，則任務可能會卡住或凍結。

如果您遇到無回應的執行該怎麼辦

• 取消執行以避免產生額外費用。

• 檢查任務日誌，以檢查是否有任何程序無法正確結束。

• 檢查引擎日誌以識別任何異常的引擎行為。

• 將無回應執行的任務和引擎日誌與成功完成的相同執行進行比較。這有助於識別可能導致無回應行為的任何差異。

• 如果您無法判斷根本原因，請提出支援案例並包含下列項目：

  • 停滯執行的 ARN 和成功完成的相同執行的 ARN。

  • 引擎日誌 （一旦執行已取消或失敗，即可使用）

  • 無回應任務的任務日誌。我們不需要工作流程中所有任務的任務日誌，即可進行故障診斷。