LSF实践专题（21）：LSF应用（application）的概念和使用

目录

设定application

application中的属性与队列的属性以及作业本身属性的重合

---

在LSF集群中，我们可以为作业设置各种属性和参数来帮助控制作业的调度、执行等方面的特点，例如在bsub提交作业时，通过-R指定关于作业资源的需求，通过-m指定对执行节点或群组的选择，通过-W指定运行时间长度限制等等。

这些参数可以在提交作业时为每一个作业单独指定，也可以在队列的设置中指定，来让所有提交到该队列的作业都自动带有相应的属性和设置。

同时，LSF还支持一个叫做application的作业属性，可以为一类作业创建一个application，并在这个application中定义作业的需求、属性，然后在提交作业的时候，只需要指定这个作业属于哪个application，那么该application中的设置和属性会自动应用到这个作业上。

设定application

application的配置文件在LSF_TOP/conf/lsbatch/{cluster_name}/configdir/lsb.applications。在配置文件里可以配置多个application，每个application 有自己的段落和名字，可以参照下面的配置格式：

设定成功之后，可以通过bapp命令查看当前集群中有哪些application，通过bapp -l命令则可以看到application的详细配置。

在提交作业的时候，通过-app选项可以指定要提交的作业属于哪一个application，而指定的application中的设置和属性就会应用到这个作业上。

通过bjobs -l，我们可以看到作业隶属于哪个application：

我们看到在bjobs -l输出的“Application”中显示了作业所属的application名字，同时，在最下方的Combined和Effective输出里，我们也可以看出，application中的RES_REQ设置已经成功应用到了作业<1162>上。

application中的属性与队列的属性以及作业本身属性的重合

在application中可以设置作业的各种需求，资源使用的一些限制和策略等等，同样的属性设置也可以在队列中实现，或者在提交作业时通过bsub的参数来设置，那么，这三种方式之间会不会产生冲突呢？

LSF为application，queue，job三个级别的作业属性设置了很详细的交互规则。

首先，最简单的情况就是，各个级别中设置的是不同的参数和属性类别。

例如作业所属的队列中设置的是MEMLIMIT，所属的application中设置的是RUNLIMIT，bsub参数设置的是rusage部分，这种情况下，只要启用各自级别里的参数和属性就可以，作业会自动获得所有这些属性。

我们在application app1中设置如下对于memory的需求：

在队列queue1中设置以下关于tmp的需求：

在作业提交时，输入对于另一个资源licA的需求：

作业提交成功以后，通过bjobs -l查看属性：

我们可以看到，对于作业<1263>，application、queue以及bsub中的资源需求全部都应用到了作业中。

如果各个级别中设置了相同类型的属性，又会怎么样呢？

在LSF中有一个默认的规则，application和bsub的作用范围要小于queue，bsub可以替代application，也就是说bsub选项的参数可以覆盖application中的参数，但是bsub和application中的参数不能超过queue里面参数带来的许可范围。我们通过实际例子看一下具体情况。

首先，我们在队列中设置rusage[mem=100]:

然后在application中设置rusage[mem=1024]：

接下来，我们提交一个作业<1364>应用到这个application和queue：

我们没有设置任何作业级别的属性，只是指定了所属的application和queue，LSF提示application级别的资源需求超出了queue级别的需求中的限制，因为在queue1里面我们只为作业预留100MB内存，而application中需要为作业预留1024MB内存，LSF是先尝试实现queue级别的需求，所以按照queue级别的需求预留100MB内存后，就无法再预留1024MB内存了，就会拒绝作业的提交。

如果我们将queue级别的rusage改成比application大，bsub就不会被拒绝了。

我们通过bjobs -l看一下作业<1364>实际的属性：

我们看到，因为application级别的rusage比queue级别的小，所以可以成功应用到作业<1364>上，作业的最终rusage也就变成了与application一致的1024MB。

接下来我们试一下bsub级别与application和queue级别的交互：

我们看到，虽然bsub中rusage的需求超过了application级别，但是可以将application中的参数覆盖，最终生效的是bsub中的参数。

我们在bsub中指定rusage[mem=2500]，这个值超过了queue1中的mem=2048，因此LSF 拒绝了作业的提交。

对于各种limit，也遵循这些同样的规则。

我们在app1中设置RUNLIMIT=10，在queue2中设置RUNLIMIT=5：

提交作业到app1和queue2将被拒绝：

提交作业到app1并在bsub指定-W 20（-W 20用于设置runlimit=20）可以成功，并且将会替换掉app1中的runlimit：

如果我们提交作业到queue2并在bsub中指定-W 20，也会被拒绝，因为bsub级别同样不能超过queue级别：

如果我们在bsub中指定一个比queue级别小的limit，就可以提交成功，并且将bsub级别中更小的limit作为生效的设置：

以上就是application的介绍，灵活运用application和queue中的设置，可以更加自由地对各类作业进行批量化的属性设置。

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