基于IBM LSF的集群任务失败原因分析

前提：

1. 行业：IC 设计

2. 集群管理系统：lsf/openlava/sge

3. 机器硬件 / 机器操作系统 / 集群服务 均正常。

在 IC 设计行业，经常有设计人员提出如下类似问题：

* 为什么我的 job fail 了？

* 为什么我的 EDA 工具没有跑完？

* 为什么这次运行没有生成任何结果？

如下是一个简单的傻瓜式问题自查贴，帮助 ICer 简单自查如上问题，并给出几种可能的常见原因分析。

以 lsf 为例，一般的集群任务执行过程如下：

bsub  "COMMAND >& log"

如果任务失败了，一般是由于两个原因导致的：

1. 任务本身原因，COMMAND 执行失败，退出码非 0。

2. 系统原因，人为 / 操作系统 / 集群管理系统 kill 了任务。

有一个简单的方法可以界定任务失败的原因，即通过查看任务的完成状态和退出码。

一般来说，如果任务完成状态正常（Done successfully），或者任务 exit 但是 exit code 小于 128，那么大概率是由于 #1 任务本身原因导致的失败。

如果任务完成状态为 exit 且 exit code 介于 128~255 之间，那么大概率是由于 #2 人为 / 操作系统 / 集群管理系统 的因素被 kill 掉了。

下面是两个例子。

1. 测试 1，任务非正常退出

执行一个任务，让任务本身非正常退出（退出码非 0）。

执行脚本如下。

把任务丢出去（jobid 为 5），它很快就完成了。

此时我们看一下这个任务的状态信息。

任务的状态为 “Completed <exit>”，且 “Exited with exit code 1”，说明任务本身完成了，但是任务退出码非 0（小于 128），这说明是由于任务本身的原因导致运行失败，这时候一般可以从 COMMAND 的 log 中查找到相关的错误信息。

如上，因为权限问题导致命令运行失败，表现在集群任务信息中即为一个小于 128 的退出码。

2. 测试 2，任务因为其它因素被 kill

丢一个任务。

任务正常运行（STAT 是 RUN）。

人为 kill 掉任务。

查看此时任务的状态和退出码。

此时可见 “Exited with exit code 130”，也就表明是因为外界因素导致的任务失败。

如果是操作系统或者集群管理系统 kill 了任务，虽然 exit code 会略有不同，但是表现相同，都会是一个大于 127 的退出码。

其实在这种情况下，如下几种是更有可能的原因：

1. 任务本身（或者任务运行机器上的其它任务）吃系统资源（尤其是 memory）太多，导致了系统宕机，或者触发了 linux 的 OOM-Killer 机制，导致任务被操作系统 kill。

2. 任务吃资源太多，且集群管理系统设置了资源限制，导致任务被集群管理系统 kill。

3. 任务超时（任务运行时间超过了 queue 的 timeout），被集群管理系统 kill。

如上因素，#1 和 #2 需要依赖机器资源监控系统来验证，#3 可以通过 job 的任务信息（开始时间和结束时间）来验证。

除此之外，还有可能因为网络 / 磁盘等不稳定因素导致任务随机性失败，这种任务失败则很难定位到具体的原因，除非问题可以反复重现。

总结一下：

导致集群任务失败的两个主要原因：

1. （EDA）任务本身因素：EDA 工具本身运行失败，一般任务的 exit code 介于 1-127 之间，大概率可以从任务日志（需要自己保存 log 哦）上查到相关错误信息。

2. 人为或系统因素：人为 / 操作系统 / 集群管理系统 kill 任务，一般任务的 exit code 介于 128-255 之间，需要辅助运行机器的监控数据（比如任务运行机器的 memory 使用曲线）来判断问题根源。