您有时候可能会遇到LSF作业异常退出的问题,其原因可能是:
-
因为LSF配置而杀掉作业的,例如设置了作业的MEMLIMIT和RUNLIMIT
-
因为OOM(Out Of Memory),操作系统自动触发杀掉进程的
-
应用程序自己退出的(例如程序发生了core dump或其它原因退出)
我们怎样进一步分析作业异常退出的问题呢?这里提供几种常见的分析方法。
方法1:
用bhist -l <jobid>查看作业信息。
如果是LSF因为配置RUNLIMIT、MEMLIMIT、CPULIMIT等策略或者bkill杀掉的作业,bhist输出中能找到相关的信息。
如果是其它原因导致作业退出,bhist -l输出中可以看到作业的退出码(exit code):
-
126:作业命令无权限执行
-
127:找不到作业命令
如果退出码大于128,则将其减去128,余值就是进程接收到的系统信号(在Linux上可以用kill -l命令查看所有系统信号),作业就是因为收到该信号而异常结束的。几个常见的退出码如下:
-
130:作业收到信号2(130-128,例如Ctrl+c)退出
-
135:作业收到信号7(135-128,system bus error)退出
-
137:作业收到信号9(137-128,被kill -9杀掉)退出
-
139:作业收到信号11(139-128,segmentation fault)退出
如果是没有明确意义的退出码,可能是应用程序自身设置的特殊退出码。
方法2:
如果作业退出问题能够稳定复现,那么用bsub提交作业时可以加上-o和-e选项。这样在作业运行时,应用程序向标准输出(stdout)产生的日志会保存到-o指定的文件中,向标准错误(stderr)产生的日志会保存到-e指定的文件中。我们就可以从-o和-e输出文件中找到线索。如果知道应用程序的日志位置,也可以直接查看应用日志来分析问题。
方法3:
如果作业是脚本,可以在脚本里插入调式和打印语句来帮助定位问题。
方法4:
如果怀疑是LSF没有启动作业进程,可以用系统工具strace来跟踪LSF的sbatchd进程和作业进程,例如用如下命令来跟踪执行:
strace -f -v -tt -T -s 1024 -o /tmp/sbd.strace -p <pid_of_sbatchd>
上面这条命令开始执行后,再提交作业,然后查看/tmp/sbd.strace日志中是否有线索。
方法5:
如果怀疑作业因为某些系统原因退出,例如OOM,除了用bhist查看作业退出码是否为137外,也可以从系统日志中(/var/log/messages或用journalctl命令查看)查找线索。
方法6:
如果作业退出码显示作业是被杀掉的,但是bhist又没有明显信息表明作业是被LSF杀掉的,也找不到被谁杀掉,可以使用Linux系统的auditd功能去分析进程是被谁杀掉的。
方法7:
如果无法确定是LSF的问题、系统环境问题还是应用程序自身的问题导致作业异常退出,也可以在LSF外面单独运行作业(即不通过bsub命令提交,而是直接在计算节点上运行应用程序),用相同的用户、环境变量和执行节点,运行参数相同的应用程序,看能否正常运行。如果可以正常运行,再进一步分析LSF方面的问题;如果不能正常运行,那么需要先分析应用程序自身的问题。
以上几种方法,在具体分析问题时,可以根据需要灵活使用。关于LSF作业的exit code,也可以参考以下链接:
欢迎关注下方微信公众号【HPC常青园】,共同交流HPC集群管理经验和最佳实践。如果您有关于HPC集群的具体需求,欢迎邮件沟通交流:hpc@ivyent.cn。