LSF实践专题（17）：资源回填（Backfill）调度策略

目录

启用backfill策略

backfill策略如何工作

只有使用了该策略的队列中的作业才可以实现backfill

总结

---

上一篇我们介绍了LSF里面的资源预留（reservation）调度策略，在配置了reservation策略的队列里，如果因为部分resource被其他正在运行的作业占用而不能满足运行条件的作业，LSF会先将可用的资源预留给这个作业，防止在等待资源释放的过程中，当前可用的资源被后续需求更低的作业占用。

那么这个reservation策略有哪些弊端呢？

其中一个比较明显的问题是，如果当前占用资源的作业需要比较长时间才能结束，而剩余可用资源又被预留给了另一个大型作业，这时，如果有一个需求资源很小的小型作业被提交到集群，也同样是不能运行的。虽然我们可以指定reservation的作业每隔一个固定时间会释放预留的资源重新调度，但是这个时间一般出于性能问题也不会设置的过于短。如果最后提交的小型作业恰恰是一个很短的作业，reservation很可能会增加他等待的时间，从而导致系统的作业吞吐率降低。

有没有一种策略能平衡一下reservation带来的弊端呢？

是有的，LSF中可以设置另一种策略——backfill。

为了讲述清晰，我们还是用实际的作业举例说明backfill策略。

启用backfill策略

首先，我们先要在队列中使用backfill。

我们仍然设置两个队列，highQ和lowQ，两个队列都启用了reservation，同时我们在highQ里还配置了另一个参数，BACKFILL = Y，用于在highQ启用backfill策略。

通过命令bqueues -l，我们可以看到highQ的调度策略里启用了backfill策略：

SCHEDULING POLICIES:  BACKFILL

backfill策略如何工作

为了方便观察，我们用slots作为竞争资源。

首先，通过bhosts -w命令，我们看到当前可用的slots为32个。

我们先提交2个-n 8的作业<631><632>占用掉其中16个slots，注意在提交时，我们加入参数-W 10，意思是这个作业有一个运行时间限制（runlimit），长度为10分钟。这个runlimit可以在bsub时指定，也可以设置在队列或者application中，那么所有提交到这个队列或者application的作业都会自动含有这个runlimit。

如果作业指定了runlimit，我们在通过bjobs -l查看作业详细信息的时候，也可以看到对应信息。

如上图所示，我们看到作业<631>显示RUNLIMIT是10.0 min，也就是我们刚才指定的10分钟。

接下来我们向队列highQ提交一个需要32个slots的作业<633>。

由于当前所剩余的可用slots数量只有16，所以作业<633>会继续等待，pending reason提示没有足够的processors（因为LSF中host上的slots对应概念为cpu个数，默认情况下，cpu的数量和slots的数量是相等的）。

队列highQ是启用了reservation策略的，所以，我们通过bjobs -l -p可以看到LSF为作业<633>预留了剩余的16个可用slots。同时，我们可以看到作业<633>的详细信息中还有一项是：

Mon Jun 13 00:36:50: Job will start no sooner than indicated time stamp;

也就是说，LSF预计作业<633>的启动时间不可能早于00:36:50， 这是为什么呢？

通过bhist检查，我们发现作业<631>的启动时间是00:26:46, 作业<632>的启动时间是00:26:50。而作业<633>想要运行，必须等到作业<631>和<632>都结束，才能得到足够的slots资源。根据作业<631>和<632>的runlimit计算，这两个作业最长有可能运行10分钟，因此它们肯定可以结束的时间分别是00:36:46和00:36:50。因此作业<633>预计的开始运行时间就是00:36:50。这个时间点将被用于backfill策略的计算。

因为占用着阻止作业<633>运行的slots，只有在00:36:50才能得到释放，所以作业<633>启动时间预计不会早于00:36:50， 这就是bjobs -l中为什么显示：

Mon Jun 13 00:36:50: Job will start no sooner than indicated time stamp;

当然，这个只是预估，实际情况可能和这个时间点有出入，比如作业<631>和<632>比预期更早结束了，又或者runlimit到达后，作业没有自己结束，LSF会负责强制结束作业，但是结束过程可能也会占用一些时间。但是作为预测调度，我们也只能尽量考虑，没办法完全预知未来的每一个细节。

这时，我们向队列highQ提交3个作业，每个作业都需要2个slots，但是第一个作业<634>不指定-W选项，第二个作业<635>指定-W 15，第三个作业<636>指定-W 5。这种场景下，会有什么情况发生呢？

我们看到，只有第三个-W 5的作业<636>成功运行了，同时，作业<633>预留的slots数量减少了2。这就是backfill策略作用的结果。

backfill是借用已经预留给其他作业的资源，在该作业等待期间来运行一些小型作业。因此，通过backfill策略运行起来的小作业，有一个不可打破的原则，就是不能影响原本预留了资源的作业运行。而作业<633>预计是00:36:50开始运行，因此，在新提交的作业里，如果预留给作业<633>的16个slots可以满足新作业的需求，同时，当前时间加上新作业的runlimit时间，早于作业<633>的预计启动时间，才可以满足backfill的条件，让新作业得到预留给作业<633>的全部或者部分资源开始运行。

提交作业<634>，<635>和<636>的时间是00:30:30，作业<634>没有runlimit，不满足backfill的条件，作业<635>的runlimit是15分钟，如果运行，结束时间就是00:45:30，比<633>的预计启动时间00:36:50要晚，所以也不能满足backfill的条件, 作业<636>的runlimit是5分钟，预计在00:35:30结束，比00:36:50早，满足backfill的条件，所以只有作业<636>通过backfill策略，分配到预留给<633>的2个slots资源得以运行。

只有使用了该策略的队列中的作业才可以实现backfill

刚才的例子中，backfill是配置在highQ上的，而reserve和backfill的作业也都是来自highQ的。那么，backfill参数和reservation是什么关系呢？其他队列的作业可以通过backfill策略使用配置了backfill参数的队列所预留的资源吗？我们通过实验来调查一下。

制造一个和上面例子中相同的预留16个slots的场景。

我们可以看到，highQ中的作业<644>预留了16个slots，预计启动时间是00:47:28。

所不同的是，我们这次将短作业<645>提交到lowQ中，并指定runlimit为3分钟。

等待一段时间后，lowQ中的作业<645>并没能通过backfill运行起来。我们再向highQ提交一个相同的短作业<646>，runlimit也是3分钟。

这一次，highQ的作业<646>则顺利通过backfill策略运行起来。

我们继续实验，将backfill参数从highQ挪到lowQ上。

我们仍然让highQ的作业<749>预留16个slots，预计启动时间是00:52:50。

这次，backfill参数是在lowQ中启用的，我们将短作业<750>提交到lowQ中。

如上图所示，lowQ中的短作业成功地通过backfill策略得到8个highQ中作业预留的slots得以运行起来。

因此，backfill的参数，是让使用了这个参数的队列中的作业，在满足backfill策略条件的前提下，使用自己或者其他队列中作业预留的资源来运行。backfill是一个很巧妙的策略，限制条件是，最开始占用资源的正在运行的作业和想要通过bacfill运行的作业，都要有runlimit属性，并且预估的时间关系能够满足不阻碍reserve资源的作业运行，才可以启用backfill策略。

总结

backfill策略我们先介绍到这里，之后我们再一起探寻LSF中各种有趣的策略，感谢大家阅读。

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