目录
当LSF集群中的作业比较多，计算资源相对有限时，难免会产生资源竞争，导致作业提交后不能立即运行。LSF中称这类作业为pending（等待）作业。
很多用户会想知道，自己的作业需要等待多久才能开始运行。如果能够知道大致的等待时间，用户就可以做一些作业相关的后续安排。
不过这个等待时间涉及集群内很多资源和调度策略的综合因素，不容易快速看出，如果LSF能够提供一个参考数据，会更有帮助。
从LSF10.1 Fix Pack6开始，LSF提供了一个叫做ALLOCATION_PLANNER的预测功能，当启用这个功能后，可以对pending作业的启动时间进行一个大致预测，当然，这个预测的结果还受一些其他因素影响，所以只能作为参考。
例如在等待期间，有其他用户提交了新的作业到更高优先级的队列；或者受faireshare等策略影响，导致在等待过程中，一些新提交的作业的优先级排到了当前pending的作业前面；又或者某个本该结束的作业，在结束过程中由于执行节点的某些系统问题，导致结束的时间比预期晚了很多，甚至不能正常结束。
对于这些情况，ALLOCATION_PLANNER功能会在每个周期根据当前集群内最新的情况对pending作业进行预测，让用户即时了解到最新预测出来的结果。
这个pending作业的预测功能，实质上是一个加速模拟器，也就是对未来一个时间段内的作业调度情况进行一个加速的模拟，其基本工作原理如下：
- LSF的服务节点会在每个周期启动一个单独的进程，通过每个作业指定的runlimit属性来预估作业结束的时间；
- 加速这个特殊进程内的时间，到达预估的作业结束时间，将作业设置为结束；
- 对作业占用的各种计算资源进行相应调整，判断有哪些pending的作业可以得到运行；
- 模拟这些运行的作业runlimit时间达到以后，将这些作业结束并释放对应的计算资源；
- 再调度一批新的pending作业，并且记录下这些pending作业得到调度的时间，反馈给自己的父进程。
因此，使用这个预测功能的前提是集群内的作业必须指定runlimit值，否则预测将无从进行。
启用ALLOCATION_PLANNER功能
这个功能由两个参数共同控制，首先需要在配置文件lsb.params中，配置ALLOCATION_PLANNER参数，这个参数可以配置为Y或如下参数：
- WINDOW[时间]，就是向前模拟多久以后的调度情况。
- MAX_TIME[时间]，是指每一个预测进程最长运行多少时间。
当参数设置为Y时，WINDOW时间段的默认值是60分钟，也就是预测未来一小时内的调度情况，如果pending作业在未来1小时之内无法得到运行，就不会得到具体的预测启动时间。MAX_TIME时间段的默认值是3分钟，也就是每个预测进程最长只会运行3分钟就会被结束，避免影响后续的预测进程。
示例
用户还可以指定一个以分钟为单位的WINDOW时间段，来预测未来指定时间段的作业调度情况。不过预测的时间段越长，集群规模和pending作业数量越大，预测所需的工作就越复杂，完成的时间越长，如果设置了过于长的时间段，导致预测行为在一个周期内结束不了，反而会造成拿不到预测数据的结果。
用户还可以通过指定分钟为单位的MAX_TIME时间段来限制每一个预测进程最长的运行时间，避免由于需要预测的作业太多导致预测进程无法顺利结束而导致的预测失败。
这个ALLOCATION_PLANNER参数是用于控制服务节点，创建用于预测的进程，并且决定该进程模拟未来多久之内的调度情况。
出于性能考虑，我们可以让预测进程只对某些application或者queue对应的pending作业进行预测，如果是这样，我们需要在想要预测的作业所属的application或者queue中，配置一个名为PLAN的参数。如果我们希望对当前集群内所有的pending作业进行预测，也可以将这个PLAN参数配置在lsb.params中。
PLAN的配置比ALLOCATION_PLANNER要复杂一些。
首先，可以简单地配置为Y，这个将为对应application或queue或者当前集群中的作业开启预测功能。
除了Y，也可以将PLAN配置为DELAY[]，MAX_JOBS[integer]和RSCHED_TIME[]。
配置为DELAY[]表示，对于新提交的作业，即使状态是pending，也不会立刻对这个作业进行预测，只有当作业pending的时间超过定义的DELAY时间后才会开始预测。
这个功能主要是避免为一些很快就能得到运行的作业进行预测，从而降低预测进程内一些不必要的负担。
配置为MAX_JOBS[integer]表示，每一个预测进程中只预测指定数量的作业，避免作业数量太多导致的预测进程运行时间过长的问题。如果不配置这个值，则对于预测多少个作业没有限制，只受预测进程中向前预测多久（即ALLOCATION_PLANNER中定义的时间长度）影响。
当PLAN=MAX_JOBS[]配置在lsb.params中，表示整个集群中只预测指定数量的pending作业，而如果配置在application或者queue中，则表示只为当前application或者queue对应的作业预测指定数量的作业。
配置为RSCHED_TIME[]时，表示预测进程每隔这个时间长度才为当前application或者queue或者当前集群的作业进行预测。比如当前集群中的作业runlimit都比较长，那么在最短的runlimit的时间内，不论我们进行多少次预测，得到的结果都不会有什么明显区别，除非有大量新的作业提交并且由于某些调度策略，排在了原有pending作业的前面。
所以，我们可以根据当前集群内，或者某些application、queue中对应的runlimit情况，来设定RSCHED_TIME[]，让预测进程免于频繁地进行结果相同的预测。
功能示例演示
我们首先在lsb.params中配置ALLOCATION_PLANNER的WINDOW为30分钟：
如图所示，我们只指定了WINDOW时间段为30分钟，所以，MAX_TIME是默认的3分钟。
然后我们定义一个名为planq的队列，并在其中定义PLAN参数，指定DELAY为5分钟。
接下来，我们提交两个作业<408><409>，将集群内的slots用满，第一个作业<408>的runlimit指定为10分钟，第二个作业<409>指定为20分钟。
然后我们向planq队列也提交两个作业<410><411>，都是需要32个slots，runlimit是15分钟。
我们通过bjobs -p3 -l命令可以看到，planq的两个作业都因为slots不够而无法运行，但是并没有看到预测信息，这是因为我们设置了PLAN的DELAY是5分钟。
我们同样还可以用命令bjobs -plan来查看作业的预估时间，但是也是因为现在还处在DELAY时间内，这个命令也无法看到预估时间。
等待5分钟之后，我们再看一下bjobs -p3 -l的输出，发现作业<410>已经有了预计开始和结束时间，bjobs -l的输出会多出一个PLANNED ALLOCATION的段落，这里就是预计运行时间的信息。
这个段落里包括了预计开始运行时间（Start time）， 预计结束时间（Finish time），同时还有一个Rank，这个Rank表示作业预测时跳过了几次时间点得到这个作业的预计开始时间，作业开始时间越早，Rank越低，不过这个数值对于我们查看作业的预计开始时间没什么具体作用。同时这里还会显示一个创建时间（Created），表示当前这条预估信息是在什么时间生成的，我们可以看到第一次得到的预估信息是在5:33:03，而作业提交时间是5:27:34，正好是作业提交后的5分钟后得到的预估信息，这与队列中设置的delay是5分钟相对应。
作业<410>预计的运行时间是5:46，这是因为<410>需要等待两个当前正在运行的作业<408>和<409>都结束，才能运行，而根据bjobs -l显示的信息，作业<408>开始时间是5:26:34，作业<409>开始时间是5:26:42。
这样第一个作业<408>的runlimit是10分钟，因此预测结束时间是5:36。第二个作业<409>runlimit是20，预测结束时间是5:46，所以作业<410>预测开始时间是5:46。
我们通过bjobs -plan可以更方便地查看作业的预计开始和结束时间：
我们看到，作业<411>的开始时间是6:01，这是因为作业<410>的runlimit是15分钟，所以预计会在6:01结束，而只有作业<410>结束，<411>才能得到足够的slots来运行。
现在我们再提交3个runlimit是10的作业<414><415><416>，每个需要16个slots。
同样，我们等到5分钟以后查看作业的预估运行时间。
我们看到作业<414>和<415>都得到了预估运行启动时间，但是作业<416>没有，这是因为<414>和<415>会在6:16将所有slots占满，并在6:26结束。所以<416>应该是在6:26开始，但是因为这一轮的预测是在5:56之前做出的，6:26已经超出了为WINDOW设置的30分钟时间段，所以暂时不会为<416>预估启动时间。
通过作业运行启动时间的预估功能，我们可以得到作业的一个大致等待时间，方便作业的提交者做一些工作安排。
欢迎关注下方微信公众号【HPC常青园】，共同交流HPC集群管理经验和最佳实践。如果您有关于HPC集群的具体需求，欢迎邮件沟通交流：hpc@ivyent.cn。
2211
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
