LSF实践专题（20）：LSF集群的资源限制功能

目录

配置方式

配置效果

---

在LSF集群对资源的各种管理策略中，有一种limit功能，目的是限制某些用户或者群组，或者部门、项目所能使用的最大资源量。

例如想要限制用户群组ug1的作业，在整个集群内占用的slot个数，又或者想要限制每一个普通用户在每个计算节点上使用的内存，使其不能超过一个固定的配额。这些都可以通过limit功能来实现。

配置方式

打开lsb.resources这个配置文件，该文件位于LSF_TOP/conf/lsbatch/{cluster_name}/configdir/ 下。

在文件中以Begin Limit和End Limit来标识limit配置段落的开始和结束，段落内的配置有垂直格式和水平格式两种方式。垂直格式就是我们所用的每一行都是参数名称+等于+参数值的方式。水平格式则是每个参数名称和值都在一个数列内，每一行都是同样多个数列组成。

一个集群中可以配置多个limit，如果用垂直格式，每个limit需要一个单独的配置段落，而使用水平方式的话，可以多个limit配置在同一个limit配置段落内，不过有些参数本身是互斥的，不能配置在同一行。比如下面这两个垂直格式的limit，一个需要QUEUES，一个需要PER_QUEUE，这两个参数是不能配置在同一行的水平格式的，所以这两个limit不能通过水平格式配置在同一个limit配置段落内。另外，HOSTS与PER_HOST，USERS与PER_USER也是互斥的。

1、垂直格式：

2、水平格式：

配置效果

配置了limit之后，需要重启mbatchd服务来让新的配置生效，可以用命令badmin mbdrestart -s来完成。

假设我们配置了上面垂直格式里的两个limit，重启mbatchd服务后，可以通过命令blimit -c来查看所有配置成功的limit。

其中，limit1表示，所有由用户tadmin1和tadmin2提交到队列normal和queue1上的作业，在每个计算节点上只能只用10个slots，USERS表示这个limit作用于所有列出的用户所使用资源的总和，同理，QUEUES表示作用于所有列出的队列中的作业所能使用的资源的总和，而PER_HOST表示当前limit作用范围是每个host上面使用的资源数量。

而limit2的含义是，所有用户提交到队列queue1或者queue2中的作业，每个队列中所有的作业在计算节点群组hostgroupA中使用的slots的总和不能超过50，并且每个队列中所有作业使用的名为licA的资源数量总和不能超过20。

我们提交几个作业看一下效果。

以用户tadmin1的身份提交一个需要2个slots的作业<955>到队列queue1，作业成功运行，稍等几秒后，我们通过命令blimits查看limit使用情况。

因为当作业运行以后，mbatchd服务进程会在下一个周期，根据收集到的作业运行情况和所使用的资源情况来检查是否需要映射到满足条件的limit中，所以要等一下，blimits的信息才会显示出作业相关的情况，等候的时间是一个mbatchd周期的时间，如果mbatchd非常繁忙，就有可能要等久一些，一般为了降低overhead，即使mbatchd没有负载，也会有一个默认10秒的周期间隔。

可以通过命令bparams -a | grep SLEEP查看MBD_SLEEP_TIME的值，这个值就是mbatchd周期的最小间隔时间，如果mbatchd前一个周期运转的时间超过了这个值，那么就直接开始后一个周期，如果没有，就等到前一个周期开始时间到当前时间达到了MBD_SLEEP_TIME才开始后一个周期。

blimits命令显示信息：

因为作业<955>对于limit1和limit2的条件都满足，所以这个作业所使用的2个slots会同时计算到limit1和limit2中：我们看到blimits显示limit1中是满足了队列queue1，用户tadmin1，在集群art1的节点malpha1上使用了2个slots，而limit的限制是10个slots，以2/10的方式显示。

对于limit2，因为作业<955>满足了队列queue1，并且当前运行的节点属于host群组hostgroupA，所以将使用的2个slots也计算到了limit2上，limit2的limit限制是50个slots，以2/50的方式显示。

接下来我们以用户root提交一个需要8个slots的作业<956>到队列queue1，同样运行在malpha1节点上，同时，我们也通过rusage让这个作业使用2个licA resource。

通过blimits查看limit情况：

与作业<955>不同，作业<956>的用户并不满足limit1的条件，所以我们看到limit1的slots使用并没有变多，还是2/10，但是作业<956>满足limit2的条件，所以，他所使用的8个slots会计算到limit2的已用slots中，limit2的slots显示变成10/50，是作业<955>和<956>所使用slots之和。同时，因为<956>也使用了2个licA，而limit2同样对于licA也有限制，因此，可以看到这一次，多了一项EXTERNAL RESOURCE LIMITS的显示，这里面显示limit2中licA限制为20个，已使用数量为2，即2/20。在LSF中，slots，内存，SWAP，TMP，r15s这些host信息为内置resource，而我们定义在lsf.shared中的其他资源统称为EXTERNAL RESOURCES。

作业<956>因为是root提交，所以不满足limit1的条件，接下来，我们以用户tadmin2提交一个与<956>相同的作业<957>：

作业<957>与<955>一样，同时满足limit1和limit2的条件，所以，所使用的slots同样会计算到limit1和limit2中。

我们看到，作业<957>运行以后，limit1的slots变为作业<955>和<957>之和，达到了limit1的限制。

这时，我们再以用户tadmin2提交一个作业<959>到满足limit1条件的另一个队列normal上，会发生什么呢？

因为limit1的条件是队列normal和queue1中，作业在同一个节点上所使用的slots总和不能超过10。虽然队列normal之前没有运行的作业，但是由于队列queue1中的作业已经在节点malpha1上使用了10个slots，因此，队列normal也不能在节点malpha1上使用更多的slots了。由于我们当前只有一个可用的节点，这样，作业<959>就会pending，我们通过bjobs -p看到pending reason是资源限制已经到达（Resource limit defined on host(s) and/or host group has been reached）, 同时10.1版本的LSF，在pending reason后面会显示出具体的limit名称，resource类型以及所配置的limit的值是多少。

我们通过bmod -q命令将作业<959>的队列修改为 queue2，因为queue2不满足limit1的条件，所以修改之后，作业可以正常运行起来。

这时我们通过blimits命令检查：

我们看到，因为作业<959>的所属队列已经修改为queue2，所以<959>使用的slots不会计算到limit1中，limit1的使用情况没有变化，而limit2中的使用情况，比刚才多了一行queue2对应的信息，作业<959>只需要1个slots，所以我们看到queue2对应信息中slots只使用了1个，即1/50。

因为limit2的条件是PER_QUEUE = queue1 queue2，表示queue1与queue2中的作业所使用的资源是分开计算的，所有queue1中作业使用的slots之和不能超过50，所有queue2中作业使用的slots之和不能超过50，并且queue1中的作业使用的slots对queue2中的作业没有影响。

我们再次向queue2提交一个作业<960>。

这个作业也在queue2上，所以会将作业<960>使用的slots与<959>使用的合并记录到limit2中的queue2里面。

通过各种不同条件的limit设定，可以让管理员更加有效的控制集群中各种计算资源的平衡，避免各个部门或项目之间对资源的过度争抢。

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