LSF实践专题（11）：LSF10.1安装包不同模板参数探秘

不知道使用LSF10.1 的小伙伴们在初次安装时有没有注意到安装配置文件（install.config）中的模板（template）选项。在LSF10.1 的安装包里一共提供了三种template可供选择，分别是默认（default）模板，高吞吐量（high-throughput）模板，和并行作业（parallel）模板。

这三个模板分别对应于不同需求的客户应用场景：

•  默认模板可作为比较平衡的模板，适用于新尝试LSF的用户或者暂时没有特殊需求的用户。

•  高吞吐量模板则适合于作业数量很多，但是每个作业所需的计算资源并不是很高，主要希望单位时间内能完成的作业数量尽可能多尽可能快的用户。

•  并行作业模板则适合于单个作业大多需求比较大量的计算资源来并发执行，比如一些高性能运算（HPC）的作业场景。

那么这三个模板具体是如何让基于同一个LSF产品来构建试用不同场景需求的集群的？如果我们在安装时没有专门指定，可否在使用了一段时间后重新调整到不同的安装模板呢？我们在下面就来一起探秘一下。

* 模板实现的奥秘

其实对于不同的安装模板，LSF的安装程序会给LSF设置不同的初始参数，这些参数是工程师针对每个不同应用场景的需求，研究出的一些比较基础的优化参数。所以通过对比这些优化参数以及配置的值，我们也能找到具体是如何优化的。这样即使安装时没有选择专门的模板，我们也可以在使用中通过参数的增减和修改来达到相同的效果，或者根据自己的具体需要进行进一步专项性的优化。

下面我们来解读一下high-throughput模板里都配置了哪些参数，并且通过与其它模板的对比来体会一下它们的作用和目的。

* SBD_SLEEP_TIME

根据文档，SBD_SLEEP_TIME 主要用于控制每个运算节点上资源负载的刷新频率。这个值越小，频率就越高，理论上得到的负载数据就越及时，但是相应的每个运算节点上的服务就要分出更多的精力来进行这些频繁的更新，对于比较老的机器或者正在运行非常占用CPU、内存等计算资源的作业的节点，可能过高的频率并不是一件好事。

这个值同时还控制着sbatchd服务中很多内部周期逻辑的频率，因此最好不要配置成超过1分钟，因为如果当前计算节点的 lim服务超过1分钟没有收到来自sbatchd服务的心跳信息，会认为当前节点的sbatchd 服务过忙或者发生问题，并向管理节点汇报，这样反而会降低当前节点的利用率。

下面我们来对比一下在三个模板中，这个参数的值分别是怎样的。

模板场景	参数取值
high throughput	3
parallel	30
default 模板	7
参数默认值	30

我们可以看到，high throughput模板中这个参数的值被配置为3，这样对于大批量的短作业应用场景来说，计算节点上的sbatchd服务可以更及时得到当前节点最新的负载情况，从而缩短不必要的等待，尽可能加快作业的更替，提高吞吐量。

并行模板中，这个值保留了默认值30秒，因为对于并行作业较多的HPC应用场景，作业本身运行的时间也比较长，过于频繁的获取当前计算节点的负载并没有太大的意义，没有必要因此而增加sbatchd服务自身的繁忙程度。

而默认模板中配置的7秒，是针对大多数常规客户的作业情况选取的一个较为折衷的数值。

根据这些情况，我们也可以通过了解自己集群里大多数作业的平均运行时间，设置一个更适合自己应用环境的取值。

* MAX_JOB_NUM 和 MIN_SWITCH_PERIOD

这两个参数都是用于控制LSF中事件日志的文件替换转移频率的，所以我们放在一起来看。

LSF的mbatchd服务会把作业运行的情况以及计算节点的管理控制行为等记录在事件日志中，一旦服务重启，就会从这些日志中取回之前的记录，使集群回到重启前的状态，避免作业或节点状态和信息的丢失。

事件日志记录的位置是$LSF_TOP/work/<clustername>/logdir/lsb.events。但是随着集群不断运行，日志里会记录越来越多的作业记录，导致日志越来越大，使得mbatchd服务在读写日志时的效率降低。同时，为了避免mbatchd服务的内存被越来越多的早已完成的作业记录占用，mbatchd会把完成时间早于一定周期的作业从内存里清除掉，对于这些作业记录，就算mbatchd重启时读进了内存，也会马上再清除出去，所以没有必要继续保存在当前使用的事件日志中，mbatchd会定期将这些标记了清除的作业记录从当前日志转移到存档日志中。而MAX_JOB_NUM 和 MIN_SWITCH_PERIOD 正是控制这个转移动作的频率的。

日志转移时，mbatchd服务会把已经完成超过一定时间的作业记录转存到名为lsb.events.1的文件中，如果文件已经存在，就会继续以.2, .3, .4 ... 来命名，同时将这些记录从lsb.evnets中清除。

MAX_JOB_NUM 表示事件日志中储存的完成状态的作业数量超过这个值时，就会启动日志转移。

MIN_SWITCH_PERIOD 则表示日志转移的最小间隔，所以只有距离上一次日志转移超过了MIN_SWITCH_PERIOD时，mbatchd才会检查当前记录的已完成作业的数量是否超过MAX_JOB_NUM，从而最终决定是否启动新的日志转移动作。

模板场景	参数取值
high throughput	100000 / 1800
parallel	10000 / 3600
default模板	10000 / 0
参数默认值	1000 / 0

上面表格中“参数取值”一列，斜线左面是 MAX_JOB_NUM 的值，斜线右面是MIN_SWITCH_PERIOD的值。我们来比较一下high throughput和parallel两个模板。

首先我们来看MIN_SWITCH_PERIOD的值，对比parallel的3600秒，high throughput模板减小了一半，变成了1800秒，也就是从间隔一小时缩减成了间隔半小时。因为high throughput模板的应用环境的特点是有大量的短作业，也就造成了相同时间段内，会产生大量的已完成作业的事件记录。为了

避免事件日志文件过于庞大，就采用了比parallel模板更短的时间间隔。但是过于频繁的日志转移也有其副作用，如果在日志文件并没有非常大的情况下就频繁进行日志迁移，同样会影响mbatchd服务的运行效能，有可能反而降低作业的调度和派发，这就需要同时使用MAX_JOB_NUM来避免没有过多已完成作业记录的情况下仅仅因为间隔到了就触发日志转移。相对于parallel模板的应用环境，high throughput模板的应用环境会更快达到同样规模的作业数量，只有增加这个参数的值才能有效避免过于频繁的转移操作。

而对于default模板里面MIN_SWITCH_PERIOD的值为0，可以理解为没有这个设置，只要MAX_JOB_NUM 的值满足了就会进行日志转移，这个配置主要使用于对集群性能没有太强要求的环境，主要目标只是避免日志文件过大造成冗余和性能浪费。

基于上述理由，如果我们发现自己集群内的日志文件经常过于庞大，可以适当减小MAX_JOB_NUM的值，使得日志转移更容易触发。如果是觉得日志转移过于频繁，可以适当增大MIN_SWITCH_PERIOD。

提示：日志转移后，bhist 命令将不能再显示被转移走的作业的信息，如果指定作业ID，会被提示找不到该作业。

* CLEAN_PERIOD 和 CLEAN_PERIOD_DONE

刚才我们提到了mbatchd服务会将完成时间超过一定周期的作业从内存中清除，这个周期时间就由这两个参数来控制。

一旦作业被从mbatchd内存中清除，不论事件日志是否转移，bjobs命令都不再能够看到这些作业，如果指定对应的作业ID，会被提示找不到相应作业。（如果这时事件日志转移未被触发，则bhist 仍可以显示对应作业的信息。）

CLEAN_PERIOD控制所有已完成作业，不论是正常完成（done） 还是出错退出（exit）的， 而CLEAN_PERIOD_DONE只控制正常完成的作业。CLEAN_PERIOD_DONE的设置，主要是为了一些特殊管理需求设立的。比如有时候管理员需要对某段时间内，非正常退出的作业进行整理分析，调查造成作业失败的主要原因，并据此对集群进行优化或升级。对于这种需求，非正常退出的作业记录就需要保留更长时间，而正常作业的记录则可以更早被清除。

从这个理念触发，CLEAN_PERIOD_DONE的值只能比CLEAN_PERIOD更小，否则就会收到警告信息，并且被忽略，只有CLEAN_PERIOD的值生效。

模板场景	参数取值
high throughput	1800 / 1800
parallel	3600 / 3600
default模板	3600 / 3600
参数默认值	3600 / 3600

对比模板的配置，我们看到high throughput模板被配置了更小的周期，因为这个模板的应用环境中，相同时间段内会产生更多的作业记录，更小的周期有助于将mbatchd服务的内存控制在可靠范围之内，避免过多的作业记录影响集群的运行效率。

* PEND_REASON_UPDATE_INTERVAL

mbschd服务负责调度整个集群中的所有作业，它会逐个检查所有作业，尝试为所有等待调度的作业找到满足需求的计算节点，如果尝试调度了某个作业但并没有找到合适的可用节点，就会为这个作业设置一个pending reason，让用户和管理员可以知道作业没有调度出去的原因，从而通过修改作业的资源需求，或者调整集群内的资源分配方案来尽可能让更多的作业可以运行，或是减少等待时间。

但是这些pending reason一开始只是在mbschd服务进程内部设置的，必须由mbschd定期发布给mbatchd服务，用户才能通过bjobs 等命令看到，这个PEND_REASON_UPDATE_INTERVAL参数就用来控制mbschd多久会发布一次pending reason。

pending reason的频繁发布会额外增加mbschd的负载，而间隔过长，可能会导致用户太久看不到作业运行但同时又不知道原因，造成使用的不便。还有一个隐藏的问题是，当等待调度的作业越多，集群规模越大，资源类型越多时，单个调度周期所用时间也会越长，所以对于作业负载比较大的集群，设置过于频繁的pending reason 发布周期也并没有太大的意义。

基于这些原因，我们再来看看这个参数在不同模板的值。

模板场景	参数取值
high throughput	60
parallel	30
default模板	30
参数默认值	30

可以看到，正如我们刚才分析的，对于high throughput模板，这个参数配置成了60秒，相当于parallel 和default模板的两倍时间，就是考虑到high throughput模板的应用环境中，作业负载会更高，mbschd服务会更加忙碌的原因。

* MAX_INFO_DIRS

mbatchd服务在派发作业到计算节点时会生成一个jobinfo文件，里面有这个作业的各种信息，让计算节点的sbatchd能够了解作业的详细信息，jobinfo文件默认的存储位置在$LSF_TOP/work/<clustername>/logdir/info下，也可以通过LSB_JOBINFO_DIR参数来修改存储位置。

对于high throughput模板的应用环境，会在短时间产生大量的作业，同时也就会有大量的作业信息，如果把这些文件都存储在同一个目录下，会对磁盘读写性能产生很大影响，从而拖慢mbatchd服务的运行效率。MAX_INFO_DIRS这个参数可以把jobinfo文件存储到不同子目录下，子目录的最大个数由这个参数指定，这样可以在一定程度上提高磁盘读写效能。

模板场景	参数取值
high throughput	500
parallel	0
default模板	0
参数默认值	0

还有另一个参数JOB_INFO_MEMORY_CACHE_SIZE用于将一部分指定大小的内存拿来存放jobinfo文件，然后隔一段时间再按需把信息转存到硬盘上，这是另一种缓解jobinfo文件带来的磁盘压力的方法。JOB_INFO_MEMORY_CACHE_SIZE的默认值是1024MB。

* 总结

上面提到的这些模板中的参数，全部都是在$LSF_TOP/conf/lsbatch/<clustername>/configdir/lsb.params文件中的，如果安装时我们没有选择high throughput模板，也完全可以手动在这个文件中配置，或者是根据自己的实际需求对参数的值进行优化和修改。

如果修改了SBD_SLEEP_TIME这个参数，需要重启所有节点上的sbatchd服务，可以在管理节点上由管理员用户执行badmin hrestart all来实现。前文提到的其它参数则重启mbatchd服务即可，由管理员用户在管理节点上执行 badmin mbdrestart或者badmin mbdrestart -s 即可。前者是尽量不影响当前mbatchd进程的情况下慢慢替换原有进程，后者则会立刻中断当前mbatchd进程并启动新进程，集群的服务可能会有短时间暂时不可用，直到新进程启动完成并且读取并回滚了所有日志记录为止。

以上就是针对high throughput安装模板中相关参数的一些个人解读，如果有些朋友觉得哪里有问题，也欢迎批评指出。在还有几个参数是parallel模板中独有的，high throughput模板并没有做特别的配置，只是使用了默认值，由于本文主要是针对high throughput安装模板的一些介绍和探讨，所以没有在这里列出，如果有专门对应HPC环境或者并行作业的研究讨论，我们可以专门解读。

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