LSF实践专题（1）：loadSched和loadStop介绍

本文链接：https://blog.csdn.net/richycn/article/details/135872866

很多LSF用户都曾经遇到过这样的问题：某些作业运行时占用了大量内存，导致计算节点运行缓慢，甚至引发OOM（Out-Of-Memory）和系统宕机。

LSF在作业调度时，会根据作业指定的内存需求（bsub -R "rusage[mem=...]"）进行节点选择，并进行内部记录，将执行节点的可用内存记为减掉rusage预留内存之后的值。LSF调度下一个作业时，会根据该节点新的内存值，决定是否分配作业到该节点执行。

理论上，只要每个作业都指定rusage参数，并且作业实际占用内存都不超过rusage指定值，就应该不会发生内存OOM的情况。但在实际中，用户往往不能准确估算作业需要的最大内存，因此指定的rusage常常不准确。用户甚至可能不指定rusage参数。还有些用户通过bsub提交一个gnome-terminal作业来启动一个终端，再在这个终端里直接运行应用程序，绕开了LSF。这些情况都会导致LSF无法控制和预测作业资源消耗，在极端情况下，就会发生OOM和系统宕机。

提交作业时指定rusage可以在一定程度上避免OOM的发生，如果结合LSF的memory limit设置（后面专题介绍），则可以进一步降低OOM的概率，但是还不能彻底解决这个问题，其主要原因在于很难做到让全部作业都指定rusage，并且指定的预留内存一定小于实际占用内存。

LSF为我们提供了一种机制，可以对计算节点的loadSched和loadStop进行设置，这样能够大大降低OOM和系统宕机风险。本文介绍有关设置，并通过示例进行讲解。

配置介绍

在lsb.hosts里增加一列，指定负载指标的loadSched和loadStop阈值。例如：为某计算节点设置其mem负载的loadSched/loadStop配置为5120/2048，生效后有如下行为：

当计算节点的可用内存低于5120MB时，LSF将该计算节点关闭（bhosts将显示该节点状态为closed_Busy），阻止新作业分配到这个计算节点上。
当计算节点的内存低于2048MB时，LSF将该节点上运行的作业逐步挂起（bjobs将显示作业状态为SSUSP），挂起策略是：

○先挂起低优先级队列的作业，再挂起高优先级队列的作业，同一个队列则挂起后运行的作业；

○最终保留一个作业运行，不会全部挂起。

当计算节点可用内存恢复高于2048MB时，LSF逐步恢复挂起的作业。
当计算节点可用内存恢复高于5120MB时，LSF将该计算节点重新open。

示例讲解

在lsb.hosts文件里增加mem一列，并为host2设置mem loadSched/loadStop为5120/2048：

Begin Host
HOST_NAME MXJ   r1m     pg    ls   mem         tmp  DISPATCH_WINDOW  AFFINITY  # Keywords
host2     !     ()      ()    ()  (5120/2048)  ()    ()               (Y)  # Example
default   !     ()      ()    ()   ()          ()    ()               (Y)  # Example
End Host

解释：

在HOST_NAME这一行添加"mem"字段；
如果不想为某些节点添加mem loadSched/loadStop，则将其mem列设置成()；
也可以将mem设置成(5120/)，即只设置mem loadSched，不设置loadStop，计算节点可用内存低于5120MB时，LSF只关闭计算节点不接受新作业，但是运行的作业不会挂起。

我们来观察作业。提交一些消耗内存的作业，当计算节点内存低于loadStop时，部分作业挂起（作业7441和7442）：

$ bjobs
JOBID   USER    STAT  QUEUE   FROM_HOST   EXEC_HOST    JOB_NAME     SUBMIT_TIME
7440    user1    RUN    normal    host1     host2     *eatmem 20   Oct 15 13:37
7441    user1    SSUSP  normal    host1     host2     *eatmem 20   Oct 15 13:37
7442    user1    SSUSP  normal    host1     host2     *eatmem 20   Oct 15 13:37
7443    user1    PEND  normal     host1               *eatmem 20   Oct 15 13:37
7444    user1    PEND  normal     host1               *eatmem 20   Oct 15 13:37

再来观察计算节点：

$ bhosts -l host2
HOST  host2
STATUS           CPUF  JL/U    MAX  NJOBS    RUN  SSUSP  USUSP    RSV DISPATCH_WINDOW
closed_Busy    116.10     -      8      3      1      2      0      0      -

CURRENT LOAD USED FOR SCHEDULING:
               r15s   r1m  r15m    ut    pg    io   ls    it   tmp   swp   mem  slots   
Total           0.0   0.0   0.0    0%   0.0     2    0    26   40G  5.9G *1.2G      5   
Reserved        0.0   0.0   0.0    0%   0.0     0    0     0    0M    0M    0M      -    

LOAD THRESHOLD USED FOR SCHEDULING:
               r15s   r1m  r15m   ut      pg    io   ls    it    tmp    swp    mem
loadSched        -     -     -     -       -     -    -     -     -      -     *5G
loadStop         -     -     -     -       -     -    -     -     -      -     *2G

从上述结果可以看到：

host2这个节点的mem loadSched/loadStop配置为5G/2G；
当前host2可用内存还有1.2G，低于配置的loadSched值（5G），计算节点的状态变为closed_Busy状态，LSF不再向这个计算节点分配新作业；
host2可用内存1.2G，低于配置的loadStop值（2G），LSF自动将作业7441和7442挂起，变成SSUSP状态，只保留作业7440正常运行；
当作业7440结束后，如果可用内存回到loadStop值（2G）以上时，LSF将恢复7441和7442作业执行；
当host2可用内存恢复到loadSched值（5G）以上时，LSF会重新open这台host，接受作业调度。

以上我们介绍了loadSched/loadStop的基本用法，在实际使用的过程中可能会遇到各种具体问题，例如：

这里配置的loadSched/loadStop并不局限于mem（内存），也可以是ut（CPU利用率）等其它资源；
具体应用中还要考虑资源的性质，比如内存在作业挂起后并不释放，但CPU是释放的。所以对作业的处理方法也不尽相同。对于不释放的资源，很多用户会将挂起的作业自动杀掉或rerun，以免计算节点因为不能恢复高于loadSched值而造成计算节点停用。

由于篇幅有限，这里不能将所有的情况都介绍到，如果您有兴趣，也可以通过公众号联系我们做具体问题具体分析。

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

HPC常青园