目录
很多LSF用户都曾经遇到过这样的问题:某些作业运行时占用了大量内存,导致计算节点运行缓慢,甚至引发OOM(Out-Of-Memory)和系统宕机。
LSF在作业调度时,会根据作业指定的内存需求(bsub -R "rusage[mem=...]")进行节点选择,并进行内部记录,将执行节点的可用内存记为减掉rusage预留内存之后的值。LSF调度下一个作业时,会根据该节点新的内存值,决定是否分配作业到该节点执行。
理论上,只要每个作业都指定rusage参数,并且作业实际占用内存都不超过rusage指定值,就应该不会发生内存OOM的情况。但在实际中,用户往往不能准确估算作业需要的最大内存,因此指定的rusage常常不准确。用户甚至可能不指定rusage参数。还有些用户通过bsub提交一个gnome-terminal作业来启动一个终端,再在这个终端里直接运行应用程序,绕开了LSF。这些情况都会导致LSF无法控制和预测作业资源消耗,在极端情况下,就会发生OOM和系统宕机。
提交作业时指定rusage可以在一定程度上避免OOM的发生,如果结合LSF的memory limit设置(后面专题介绍),则可以进一步降低OOM的概率,但是还不能彻底解决这个问题,其主要原因在于很难做到让全部作业都指定rusage,并且指定的预留内存一定小于实际占用内存。
LSF为我们提供了一种机制,可以对计算节点的loadSched和loadStop进行设置,这样能够大大降低OOM和系统宕机风险。本文介绍有关设置,并通过示例进行讲解。
配置介绍
在lsb.hosts里增加一列,指定负载指标的loadSched和loadStop阈值。例如:为某计算节点设置其mem负载的loadSched/loadStop配置为5120/2048,生效后有如下行为:
- 当计算节点的可用内存低于5120MB时,LSF将该计算节点关闭(bhosts将显示该节点状态为closed_Busy),阻止新作业分配到这个计算节点上。
- 当计算节点的内存低于2048MB时,LSF将该节点上运行的作业逐步挂起(bjobs将显示作业状态为SSUSP),挂起策略是:
○先挂起低优先级队列的作业,再挂起高优先级队列的作业,同一个队列则挂起后运行的作业;
○最终保留一个作业运行,不会全部挂起。
- 当计算节点可用内存恢复高于2048MB时,LSF逐步恢复挂起的作业。
-
当计算节点可用内存恢复高于5120MB时,LSF将该计算节点重新open。
示例讲解
在lsb.hosts文件里增加mem一列,并为host2设置mem loadSched/loadStop为5120/2048:
Begin Host
HOST_NAME MXJ r1m pg ls mem tmp DISPATCH_WINDOW AFFINITY # Keywords
host2 ! () () () (5120/2048) () () (Y) # Example
default ! () () () () () () (Y) # Example
End Host
解释:
- 在HOST_NAME这一行添加"mem"字段;
- 如果不想为某些节点添加mem loadSched/loadStop,则将其mem列设置成();
- 也可以将mem设置成(5120/),即只设置mem loadSched,不设置loadStop,计算节点可用内存低于5120MB时,LSF只关闭计算节点不接受新作业,但是运行的作业不会挂起。
我们来观察作业。提交一些消耗内存的作业,当计算节点内存低于loadStop时,部分作业挂起(作业7441和7442):
$ bjobs
JOBID USER STAT QUEUE FROM_HOST EXEC_HOST JOB_NAME SUBMIT_TIME
7440 user1 RUN normal host1 host2 *eatmem 20 Oct 15 13:37
7441 user1 SSUSP normal host1 host2 *eatmem 20 Oct 15 13:37
7442 user1 SSUSP normal host1 host2 *eatmem 20 Oct 15 13:37
7443 user1 PEND normal host1 *eatmem 20 Oct 15 13:37
7444 user1 PEND normal host1 *eatmem 20 Oct 15 13:37
再来观察计算节点:
$ bhosts -l host2
HOST host2
STATUS CPUF JL/U MAX NJOBS RUN SSUSP USUSP RSV DISPATCH_WINDOW
closed_Busy 116.10 - 8 3 1 2 0 0 -
CURRENT LOAD USED FOR SCHEDULING:
r15s r1m r15m ut pg io ls it tmp swp mem slots
Total 0.0 0.0 0.0 0% 0.0 2 0 26 40G 5.9G *1.2G 5
Reserved 0.0 0.0 0.0 0% 0.0 0 0 0 0M 0M 0M -
LOAD THRESHOLD USED FOR SCHEDULING:
r15s r1m r15m ut pg io ls it tmp swp mem
loadSched - - - - - - - - - - *5G
loadStop - - - - - - - - - - *2G
从上述结果可以看到:
- host2这个节点的mem loadSched/loadStop配置为5G/2G;
- 当前host2可用内存还有1.2G,低于配置的loadSched值(5G),计算节点的状态变为closed_Busy状态,LSF不再向这个计算节点分配新作业;
- host2可用内存1.2G,低于配置的loadStop值(2G),LSF自动将作业7441和7442挂起,变成SSUSP状态,只保留作业7440正常运行;
- 当作业7440结束后,如果可用内存回到loadStop值(2G)以上时,LSF将恢复7441和7442作业执行;
- 当host2可用内存恢复到loadSched值(5G)以上时,LSF会重新open这台host,接受作业调度。
以上我们介绍了loadSched/loadStop的基本用法,在实际使用的过程中可能会遇到各种具体问题,例如:
- 这里配置的loadSched/loadStop并不局限于mem(内存),也可以是ut(CPU利用率)等其它资源;
- 具体应用中还要考虑资源的性质,比如内存在作业挂起后并不释放,但CPU是释放的。所以对作业的处理方法也不尽相同。对于不释放的资源,很多用户会将挂起的作业自动杀掉或rerun,以免计算节点因为不能恢复高于loadSched值而造成计算节点停用。
由于篇幅有限,这里不能将所有的情况都介绍到,如果您有兴趣,也可以通过公众号联系我们做具体问题具体分析。
欢迎关注下方微信公众号【HPC常青园】,共同交流HPC集群管理经验和最佳实践。如果您有关于HPC集群的具体需求,欢迎邮件沟通交流:hpc@ivyent.cn。