【科研利器】slurm作业调度系统(三)
“ 大家好哇！上一期我们介绍了提交批处理任务的整个流程，包括查看资源、编写脚本、提交作业、查询作业信息等内容。今天呢，我们主要就作业脚本中两个非常重要的概念 Partition和 QoS 进行介绍，并给出一些实用技巧。”
1
理解Partition
要想彻底理解分区，我们首先要搞清楚分区(Partition)是什么。它其实可以看作为一些节点的集合，是为了实现某一类功能而整合起来的一套计算资源的配置，每个分区都有自己的限制。举个例子来理解，如下表所示，我们有两个分区：cpu 分区和 gpu 分区。他们各自的资源配置不同，有的有 cpu 节点，有的有 gpu 节点。如果我们现在想做一个简单的但是计算量大的工作，我们该选择哪个分区呢？显然是 gpu 分区对不对？因为它含有 gpu 节点，这样的简单重复性工作是它天然的优势。由此可见，由于不同的节点的特性和硬件属性不同，设置分区可以帮助用户更好地根据其下面所配置的节点的特点以及自己作业的需求，选择最适合自己的分区进行运算，提高效率。如果集群中部分机器是私有的，那么设置分区还可以使得只有部分用户能在这个分区提交作业，减少作业的排队时间。
不同分区除了计算资源的配置不同外，他们的最长作业时间限制也大多不同(从上表可以看出)。这点在编写作业脚本中选择分区时候需要考虑到，根据自己作业运行的大致时间确定合适的分区。否则当你的作业到达分区最长限制时间时，会被自动杀死(惨兮兮，又要重排队了)。当然，如果万不得已还是超了的话，也有补救方法，那就是联系超算管理员，让他给你单独延长作业时间。
总结一下，选择分区的时候，首先需要关注该分区计算资源的配置，是否有利于你作业的运行(如是否有 gpu 节点、节点数够不够多、内存够不够大等)。其次，需要了解该分区的最大作业时长是多少，是否能够跑完你的作业。最后一点，关注该分区节点的状态，在有多个分区的配置满足任务需求的时候，当然选择那个排队少的分区啦(关于如何查看节点状态，可见【科研利器】slurm作业调度系统(二))。
2
理解QoS
那作业脚本中常见的 QoS 又是什么呢？QoS(Quality ofService)和分区不同，它表示服务质量，它更多刻画了作业的属性而非节点的属性。不同任务的特性不同，指定 QoS 可以使得资源更好分配。例如，用户若只是想简单调试自己的程序，而非大规模地运行，那么这样的作业的特点是“短时间”，“用户对结果的需求很迫切”。为这样的作业设计 QoS 是非常有必要的。如下表所示两种 QoS，用户可根据需求自行选择。从中可以看到 debug 的 QoS 优先级高，但对每个用户的可用资源也相应变少。
这里需要注意的是当 QoS 和 Partition 同时指定最大运行时间时，以二者限制最严格的为准。例如，指定 QoS 为 debug 并提交到 cpu 分区中，则最长运行时间为3小时。指定 QoS 为normal 并提交到 cpu 分区中，则最长运行时间为7天。
对于收费集群，用户需要指定 QoS，不同 QoS 的执行优先级不同，收费也不同。通过sacctmgr 命令可以查询每个用户在每个分区下可用的QoS，具体可以通过 -h 参数进行学习。
3
几个实用技巧
查询历史作业
当我们把作业提交到超算上之后，在作业没有完成之前，我们都可以通过之前讲解过的 squeue 命令查询任务状态。但一旦作业结束之后，squeue 命令是无法看到历史作业状态的。因为我们并不会盯着 squeue看，所以有时候不清楚作业到底是正常跑完了结束还是因为报错退出了。这时候便可以用 sacct 命令来查看历史作业。
1)默认情况下，用户仅能查看属于自己的历史作业。直接使用 sacct 命令会输出从当天 00:00:00 起到现在的全部作业。
2)如果使用如下命令，则会输出从 MM 月 DD 日起的所有历史作业。
$ sacct -S MMDD3)默认情况会输出作业 ID，作业名，分区，账户，分配的 CPU，任务结束状态，返回码。当然我们还可以使用 --format 参数来指定到底要输出那些指标。
[xiazh@login]$ sacct --format=jobid,user,alloccpu,allocgres,state%15,exitcode
JobID User AllocCPUS AllocGRES State ExitCode
------------ --------- ---------- ------------ --------------- --------
104 xiazh 1 gpu:1 COMPLETED 0:0
141 xiazh 12 CANCELLED by 0 0:0
142 xiazh 1 FAILED 2:0在这里我们详细显示了作业 ID，用户，申请的 CPU，申请的 GPU，任务结束状态，返回码，其中我们比较感兴趣的是任务结束状态。在这里我们看到，JOBID 为 141 的作业的状态是 CANCELLED by 0，这里 0 表示系统的 root 用户。这条信息表示：我们的任务被集群的超级管理员强制取消了！这就需要询问管理员具体的原因了。另外， JOBID 为 142 作业的状态是 FAILED，它的含义是我们的作业脚本中有命令异常退出，这时候就需要检查我们的 slurm 脚本的命令部分或者是查看运行环境了。
更新任务设置
有时我们很早就提交了任务，但是在任务开始前却发现作业的属性写错了（例如提交错了分区，忘记申请 GPU 个数），取消了重新排队似乎很不划算。如果作业恰好还没有运行我们是可以通过 scontrol 命令来修改作业的属性。
由于可修改的属性非常多，我们可以借助 slurm 自动补全功能来查看可修改的内容。这只需要我们在输入完 JOBID 后空一格并敲两下 TAB 键。
[xiazh@login ~]$ scontrol update jobid=520 <TAB><TAB>
account=<account> mintmpdisknode=<megabytes> reqnodelist=<nodes>
conn-type=<type> name> reqsockets=<count>
contiguous=<yes|no> name=<name> reqthreads=<count>
dependency=<dependency_list> nice[=delta] requeue=<0|1>
eligibletime=yyyy-mm-dd nodelist=<nodes> reservationname=<name>
excnodelist=<nodes> numcpus=<min_count[-max_count] rotate=<yes|no>
features=<features> numnodes=<min_count[-max_count]> shared=<yes|no>
geometry=<geo> numtasks=<count> starttime=yyyy-mm-dd
gres=<list> or switches=<count>[@<max-time-to-wait>]
licenses=<name> partition=<name> timelimit=[d-]h:m:s
mincpusnode=<count> priority=<number> userid=<UID
minmemorycpu=<megabytes> qos=<name> wckey=<key>
minmemorynode=<megabytes> reqcores=<count>例如我要更改当前的分区到 gpu，并且申请 1 块卡，可以输入
scontrol update jobid=938 partition=gpu gres=gpu:1注意变更的时候仍然不能超过系统规定的上限。变更成功后，作业的优先级可能需要重新来计算。
当任务已经开始运行时，一般不可以再变更申请资源，分区等参数。特别地，如果发现自己低估了任务运行时间，用户不能使用 scontrol 命令延长任务最大时间。但是可以根据需求减少任务的最大时间。若确实有延长任务时间的急切需求请联系超算管理员。
以上就是本期的全部内容啦，快来一起实践吧！
参考资料：
https://bicmr.pku.edu.cn/~wenzw/pages/slurm.html#partition