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

原创
2020/11/02 20:24
阅读数 7.8K

前提:

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使用曲线)来判断问题根源。

 

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部