LSF实践专题（36）：对LSF中作业的pending reason进行分类查看

目录

pending reason的不同类别

pending reason的不同级别

查看不同类别的pending reason

---

当LSF集群中作业比较多，出现某些资源不够用的时候，就会有作业pending的状态。

在LSF实践专题（31）：等待作业启动时间预测中，介绍过一个pending作业启动时间的预测功能——ALLOCATION_PLANNER，可以方便作业的提交者做一些工作安排。

同时，LSF会给每个pending作业设置一个pending reason，让用户知道作业为什么没能马上开始运行，并且可以尝试调整作业的需求来让作业更早运行起来。而这些作业的pending reason各种各样，我们可以通过分类进行解读。

pending reason的不同类别

LSF中的pending reason有两个大的类别：

main reason和host reason。

• 如果作业由于main reason导致pending，那么这个作业在整个集群中的任何一台机器上都无法运行。

• 如果是由于某个计算节点上的某些原因导致作业无法在这个节点上运行，那么这个节点上就会有一个相应的host reason，如果所有的节点对于这个作业都设置了host reason，那么这个作业找不到任何可以运行的节点，也会导致pending。

例如，我们给队列q3设置了limit，限制最多只能使用50个slots，当这个队列中的作业已经使用了50个slots，新提交的作业<935>就无法运行，直到某些作业结束，释放出足够的slots。

此时，<935>就会显示以下pending reason：

一旦作业设置了一个main reason，就不会显示其他reason，因为只要导致这个main reason的情形存在，这个作业就不可能运行。

而host reason，有可能多个节点都是相同的reason，也有可能有些节点会有不同类型的host reason，比如节点1-3是由于slots不够，而节点4-6是由于内存不够，那么节点1-3就会显示当前节点slots不够的host reason，节点4-6就会显示当前节点内存不足的host reason。

如上图所示，整个集群中有4个节点，其中3个节点由于状态是unavailable的不可用状态，导致作业<936>不能运行，另外一个节点由于没有足够多的内存满足作业的内存需求，导致不能运行。

一般来讲，由于作业所属的队列、提交作业的用户相关的limit等限制，导致作业不能运行的，这类原因与具体的节点无关，这类reason就被划分为main reason；而由于某个节点上的属性不满足需求导致作业不能运行，这类reason就会被划分为host reason，例如节点的状态，节点上的内存，CPU个数等。

而如果因为作业需要的resource不满足，导致作业不能运行，这时要根据具体的resource属性来决定作业的pending reason类别。

如果resource是整个集群共享的，那么resource不足的时候，整个集群没有任何节点可以运行这个作业，这时的reason就是main reason；而如果resource是每个节点上有不同的值，或者只有一部分节点有这种resource，那么相关的reason就是host reason。

例如，licD这个自定义资源在每个节点上都有5个，现在malpha1上剩余1个可用，而当前除了这个节点，其他节点都是不可用状态，则由于这个resource不够导致作业<943>处于pending状态，就会在malpha1上显示licD不够的host reason：

再来看另外一个例子。我们配置一个集群共享的resource，名字叫newres999，当前剩余可用个数是5，如果我们提交一个需要6个newres999的作业<944>，就会显示resource不够的main reason：

pending reason的不同级别

如果作业的pending reason是main reason，就比较一目了然，但如果是host reason，且集群内有很多节点时，可能会显示很多不同的host reason，看起来就不那么直观了。

在LSF10.1中，将这些host reason进行了分类，分为了candidate host reason和non-candidate host reason两大类。

例如当前这个作业<943>：

这个例子中，有一个host是因为licD这个resource不够而导致作业<943>不能运行，当释放出足够多的licD资源后，作业就可以在这个节点运行，这类reason称为candidate host reason。而另外三个节点的状态是unavailable，这有可能是网络问题导致的，也有可能是节点有故障，总之在节点恢复之前都不可能运行作业，这类reason就被分为non-candidate host reason。 

简单来说就是，如果是由于当前运行的作业将节点上的某些资源占用，这类reason被称为candidate host reason，等待一段时间之后，作业就有可能在相应节点运行。

如果当前节点由于其他一些原因导致不能运行任何作业，那么这类reason就被称为non-candidate host reason，这类节点我们很难判断要等待多久才能恢复。

查看不同类别的pending reason

在查看pending reason时，我们可以指定查看哪类pending reason。在命令bjobs -p后面可以指定pending reason level，例如，bjobs -p3，就是查看level 3的pending reason，bjobs -p2 和bjobs -p1分别是查看level 2和level 1的pending reason。Level也可以与其他bjobs参数一起使用，例如 bjobs -p3 -l。

那么这些不同level是什么意思呢？

• Level 3表示显示所有reason，包括candidate host reason和non-candidate host reason。

• Level 2表示只显示candidate host reason。

• Level 1表示只显示key reason。

Key reason是最主要的reason，如果有main reason，key reason自然就是main reason，如果作业有candidate host reason，则从所有candidate host reason中选择一个对应的节点最多的，作为key reason，如果作业只有non-candidate host reason，则会显示“There are no suitable hosts for the job”， 表示当前集群内所有的机器都暂时不能运行这个作业。

例如：

上面这个作业<942>有一个candidate host reason，所以bjobs -p2 和bjobs -p1都只显示这个reason。

上面这个作业<943>所有的reason都是non-candidate host reason，所以bjobs -p2显示candidate host reason的数量是0，而bjobs -p1则显示没有适合这个作业的节点。

这个pending reason level，也可以在配置文件lsf.conf中通过参数LSB_BJOBS_PENDREASON_LEVEL提前设置好，例如设置了LSB_BJOBS_PENDREASON_LEVEL=1，那么bjobs -p就相当于bjobs  -p1，但是这个只是默认的level，可以通过命令行查看指定的level，例如：

LSF还提供了一个bjobs  -psum的命令，可以将当前集群里所有pending作业的pending reason进行统计显示，方便集群管理员查看当前集群中哪些资源导致的pending作业最多。

-psum也可以和-p level一起使用，比如因为我设置的默认level是1，所以只使用bjobs -psum就相当于bjobs -psum -p1，只会统计所有的main reason和key reason。

如果使用bjobs -psum -p3，则会统计所有类型的reason。

欢迎关注下方微信公众号【HPC常青园】，共同交流HPC集群管理经验和最佳实践。如果您有关于HPC集群的具体需求，欢迎邮件沟通交流：hpc@ivyent.cn。