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

# 运行失败原因
<a name="workflows-run-errors"></a>

如果运行失败，请使用 [GetRun](https://docs.aws.amazon.com/omics/latest/api/API_GetRun.html)API 操作检索失败原因。

查看失败原因以帮助您解决运行失败的原因。下表列出了每个失败原因以及错误描述。


| 失败原因 | 错误描述 | 
| --- | --- | 
|  假设角色失败  |  HealthOmics 没有担任该角色的权限。为角色指定信任关系中的 HealthOmics委托人。  | 
|  无法启动容器错误  |  无法启动工作流程任务:*name*，ID：使用图像的*ID*容器：*image name*。请确保图像有效，然后重试。  | 
|  无法启动容器大小错误  |  无法启动工作流程任务:*name*，ID：使用图像的*ID*容器：*image name*。请确保图像大小小于 45 GiB（GPU 实例为 95 GiB），然后重试。  | 
| ECR\$1permission\$1error | HealthOmics 没有访问图片 URI 的权限。确认 Amazon ECR 私有存储库存在并且已授予对 HealthOmics 服务主体的访问权限。 | 
|  导出失败  |  导出失败。检查输出存储桶是否存在以及运行角色是否具有该存储桶的写入权限。  | 
|  文件系统空间不足  | 文件系统没有足够的空间。增加文件系统的大小，然后再次运行。 | 
|  图片验证失败  |  无法验证图片*image name*。要更正此问题，请尝试拉取镜像，然后再次将其推送到您的 ECR 存储库。  | 
|  导入失败  |  导入失败。检查输入文件是否存在以及运行角色是否可以访问输入。  | 
| INACTIVE\$1OMICS\$1storage\$1RESOURCE  |  存 HealthOmics 储 URI 未处于活动状态。激活读取集并重试。要了解有关激活读集的更多信息，请参阅[在中激活读取集 HealthOmics](activating-read-sets.md)。  | 
| 未找到输入 URI | 提供的 URI 不存在:uri. 检查 URI 路径是否存在并确认该角色可以访问该对象。 | 
|  实例预留失败  |  实例容量不足，无法完成工作流程运行。请稍候，再次尝试运行工作流程。  | 
| 无效\$1ECR\$1IMAGE\$1URI |  Amazon ECR 图片 URI 结构无效。请提供有效的 URI，然后重试。  | 
|  任务资源值无效  | 请求的 GPU、CPU 或内存要么太高，无法提供可用的计算容量，要么小于任务的最小值 1 ID。 | 
|  URI 输入无效  | URI 结构无效uri。请检查 URI 结构并重试。 | 
|  修改后的输入资源  |  运行开始后，所提供*uri*的 URI 已被修改。重试运行。  | 
|  内存不足错误  |  工作流程任务*ID*内存不足。增加工作流程定义中的内存值，然后重试运行。  | 
|  运行任务失败  |  由于任务失败，运行失败。要调试任务失败，请使用 **GetRunTask**API 操作和 Amazon CloudWatch 日志流。  | 
|  RUN\$1TIMED\$1OUT  |  *number*几分钟后运行超时。  | 
|  服务错误  | 服务中出现暂时性错误。再次尝试运行工作流程。 | 
| TASK\$1TIMED\$1OUT | 任务在number几秒钟后id超时。 | 
|  不支持的输入大小  |  总输入大小太高。请减小输入大小，然后重试。  | 
|  工作流\$1运行\$1失败  |  工作流程运行失败。查看 CloudWatch 日志引擎日志流：*ID*以调试故障。  | 
|  工作流版本验证失败  |  HealthOmics 不支持请求的 Nextflow 版本:*version*--。支持的最新版本是*version*。请将您的 Nextflow 版本修改为支持的版本，然后重试。  | 
|  不支持的\$1GPU\$1实例\$1类型  |  中不支持请求的实例类型*Region*。使用该区域支持的 GPU 实例类型重试运行。可用的实例类型有*GPU instance types*。  | 

## 无响应跑步指南
<a name="workflows-guidance-unresponsive-runs"></a>

在开发新的工作流程时，如果您的代码存在问题，并且任务无法正常退出进程，则运行或特定任务可能会变得 “卡住” 或 “挂起”。这可能很难进行故障排除和 catch，因为任务长时间运行是正常的。要防止和识别无响应的运行，请遵循以下各节中建议的最佳做法。

**防止运行无响应的最佳实践**
+ 确保您正在关闭任务代码中打开的所有文件。打开太多文件有时会导致工作流程引擎出现线程问题。
+ 工作流任务创建的后台进程应在任务退出时退出。但是，如果后台进程无法干净退出，则必须在任务代码中明确关闭该进程。
+ 确保您的进程不会在不退出的情况下循环。这可能会导致运行无响应，需要更改工作流程定义代码才能解决。
+ 为您的任务提供适当的内存和 CPU 分配。分析[CloudWatch 日志](https://docs.aws.amazon.com/omics/latest/dev/monitoring-cloudwatch-logs.html)或使用成功完成工作流运行时的计算分配来验证您的计算分配是否最佳。[运行分析器](workflows-run-optimize.md#workflows-run-analyzer)使用 Run Analyzer `headroom` 参数添加额外的余量，确保流程有足够的资源来完成。在分配的内存和 CPU 中包括至少 5% 的余量，以考虑后台操作系统进程。
  + 此外，如果实例需要更高的吞吐量，请增加实例带宽大小。小于 16 vCPUs （大小为 4xl 及更小）的 Amazon EC2 实例可能会出现吞吐量激增的情况。有关 Amazon EC2 实例吞吐量的更多信息，请参阅[亚马逊 EC2 可用实例带宽](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-network-bandwidth.html#available-instance-bandwidth)。
+ 确保在运行时使用了正确的文件系统大小。对于使用静态运行存储的无响应运行，可以考虑增加静态运行存储分配，以便在文件系统上实现更高的 IO 吞吐量和存储容量。分析运行清单以查看最大文件系统存储空间，使用运行分析器确定是否需要增加文件系统分配。

**捕捉无响应的跑步的最佳实践**
+ 开发新工作流程时，请使用设置了最大运行时间限制的运行组来捕获 runaway 代码。例如，如果运行需要 1 小时才能完成，则将其放入在 2 或 3 小时（或根据您的用例不同的时间段）后超时的运行组中，以捕获失控的作业。此外，应用缓冲区以考虑处理时间的差异。
+ 设置一系列具有不同最大运行时间限制的运行组。例如，您可以根据您的预期工作流程持续时间将短期运行分配给一个在几小时后终止运行的运行组，以及一个在几天后终止运行的长跑组。
+ HealthOmics 默认的最大运行持续时间服务限制为 604,800 秒或 7 天，可通过配额工具中的请求进行调整。只有当您的跑步持续时间接近一周时，才可以申请增加此配额的服务限制。如果您同时使用短跑和长跑，并且不使用运行组，请考虑将长时间运行的运行放在具有更高最大运行持续时间服务限制的单独帐户中。
+ 检查[CloudWatch 日志](https://docs.aws.amazon.com/omics/latest/dev/monitoring-cloudwatch-logs.html)中是否有您怀疑可能没有响应的任务。如果任务通常会输出常规日志语句，但长时间没有这样做，则该任务很可能被卡住或冻结。

**如果遇到无响应的跑步怎么办**
+ 取消运行以避免产生额外费用。
+ 检查[任务日志](https://docs.aws.amazon.com/omics/latest/dev/monitoring-cloudwatch-logs.html#cloudwatch-logs)，检查是否有任何进程未能正确退出。
+ 检查引[擎日志](https://docs.aws.amazon.com/omics/latest/dev/monitoring-cloudwatch-logs.html#cloudwatch-logs)以识别任何异常的发动机行为。
+ 将无响应运行的任务和引擎日志与成功完成的相同运行的任务和引擎日志进行比较。这可以帮助识别可能导致无响应行为的任何差异。
+ 如果您无法确定根本原因，请提出[支持案例](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html#creating-a-support-case)并提供以下内容：
  + 卡住运行的 ARN 和成功完成的相同运行的 ARN。
  + 引擎日志（运行取消或失败后可用）
  + 无响应任务的任务日志。我们不需要工作流程中所有任务的任务日志即可进行故障排除。