什么是分区，为什么要指定

不同的节点的特性和硬件属性不同，设置分区可以帮助用户更好确定节点的特点，进而 选择最适合自己的节点进行运算。此外，如果集群中部分机器是私有的，那么设置分区 可以使得只有部分用户能在这个分区提交作业。总的来说，分区(Partition)可看做 一系列节点的集合。

目前我们只有两个分区

什么是 QoS，为什么要指定

和分区不同，QoS 表示服务质量，它更多刻画了作业的属性而非节点的属性。不同任务 的特性不同，指定 QoS 可以使得资源更好分配。例如，用户若只是想简单调试自己的 程序，而非大规模地运行，那么这样的作业的特点是“短时间”，“用户对结果的需求 很迫切”。为这样的作业设计 QoS 是非常有必要的。

目前我们设计了两种 QoS，用户可根据需求自行选择。若不加指定，normal 为所有用户 的默认 QoS。

可以看到 debug 的 QoS 优先级高，但对每个用户的可用资源也相应变少。

SLURM 提供了丰富的追踪任务的命令，例如 scontrol ， sacct 等。这些 命令有助于查看正在运行或已完成的任务状态。当用户认为任务异常时，可使用这些 工具来追踪任务的信息。

对于正在运行或排队的任务，可以使用

其中 JOBID 是正在运行的作业 ID，如果忘记 ID 可以使用 squeue -u USERNAME 来 查看目前处于运行中的作业。

scontrol 命令输出的信息非常多，在这里不一一列举。

作业完成后，需要用 sacct 命令来查看历史作业。默认情况下，用户仅能查看属于 自己的历史作业。直接使用 sacct 命令会输出从当天 00:00:00 起到现在的全部作业

则会输出从 MM 月 DD 日起的所有历史作业。

默认情况会输出作业 ID，作业名，分区，账户，分配的 CPU，任务结束状态，返回码。 当然我们还可以使用 --format 参数来指定到底要输出那些指标。

在这里我们详细显示了作业 ID，用户，申请的 CPU，申请的 GPU，任务结束状态， 返回码，其中我们比较感兴趣的是任务结束状态。在这里我们看到，JOBID 为 141 的 作业的状态是 CANCELLED by 0，这里 0 表示系统的 root 用户。这条信息表示：我们 的任务被集群的超级管理员强制取消了！这就需要询问管理员具体的原因了。另外， JOBID 为 142 作业的状态是 FAILED，它的含义是我们的作业脚本中有命令异常退出， 这时候就需要检查我们的 SLURM 脚本的命令部分或者是查看运行环境了。

有时我们很早就提交了任务，但是在任务开始前却发现作业的属性写错了（例如提交错 了分区，忘记申请 GPU 个数），取消了重新排队似乎很不划算。如果作业恰好没在运行 我们是可以通过 scontrol 命令来修改作业的属性。

使用以下命令可以修改 JOBID 任务的部分属性

由于可修改的属性非常多，我们可以借助 SLURM 自动补全功能来查看可修改的内容。 这只需要我们在输入完 JOBID 后空一格并敲两下 <TAB> 键。

例如我要更改当前的分区到 gpu，并且申请 1 块卡，可以输入

注意变更的时候仍然不能超过系统规定的上限。变更成功后，作业的优先级可能需要重新

当任务已经开始运行时，一般不可以再变更申请资源，分区等参数。特别地，如果发现 自己低估了任务运行时间， 用户不能使用 scontrol 命令延长任务最大时间 。但是可以 根据需求减少任务的最大时间。若确实有延长任务时间的急切需求请联系管理员。

很多时候我们需要运行一组作业，这些作业所需的资源和内容非常相似，只是一些参数 不相同。这个时候借助 Job Array 就可以很方便地批量提交这些作业。Job Array 中的 每一个作业在调度时视为独立的作业，仍然受到队列以及服务器的资源限制。

在脚本运行中，SLURM 使用环境变量来表示作业数组，具体为

可用以上变量来区分不同组内的任务，以便于处理不同的输入参数。

对于每个数组内的作业，它的默认输出文件的命名方式为 slurm-JOBID_TASKID.out 。

下面是一个很小的 SLURM 脚本例子，它使用 Job Array 来返回一些预设数组中的不同元素。 在实际应用中，这些不同的字符串或许就是程序所需输入的文件名。当然你也可以使用一 个脚本来包装你的程序，然后在这个脚本中获取这个环境变量。

提交以上脚本并使用 squeue 命令查看可以看到下面的结果：

作业 ID 是 50，而作业数组 ID 中的每个元素的命名方式为 JOBID_TASKID ，非常 容易分辨。

以下是其中某个作业的输出：

这正符合我们的预期。

取消作业数组的部分或全部任务可以使用 scancel 命令。

用户提交作业后，是否运行取决于用户申请的资源情况和当前系统的情况。建议使用 squeue 命令来查看所有已经提交和正在运行的作业。其中 NODELIST(REASON) 一栏 包含非常有用的信息，在作业未运行时，它会显示未运行的原因；当作业在运行时，它 会显示作业是在哪个节点运行的。

下面的表格整理了常见作业未运行的原因，用户可根据此来调整自己的脚本。其中的 加粗 部分 表示 异常原因 ，用户需要 修改 SLURM 脚本 或 联系管理员 。

用户申请的资源超过当前 QoS 限制时，SLURM 会直接拒绝该任务。当申请的资源超过 当前分区限制时，任务提交成功但是永远不会被运行。

在一般情况下，用户不能通过 ssh 的方式直接连接任何一台计算节点。

如上所示，直接尝试登录 comput1 节点会被拒绝。原因是在当前节点没有和你有关

如果自己在相应节点有一个任务，则用户 可以 通过 ssh 的方式进入该节点。并且只会 获取和自己任务相关的那一部分资源。

此 SLURM 脚本中申请了 4 核心 CPU 和 1 块 GPU 卡，现在尝试登录目标节点 comput6

可以看到已经成功进入了计算节点。使用 nvidia-smi 与 matlab 查看可用资源。

只看到了一块 GPU 卡。

只看到了 4 个可用 CPU 核心。

若超出任务最大时间，用户则会自动登出计算节点，所有未能按时结束的进程会自动终止。

若在目标节点上有两个或以上任务，使用 ssh 登录时会取得最近一次提交的任务所相关

考虑到多数用户已经习惯了 PBS 作业调度系统，这里整理了 PBS 和 SLURM 使用的 对应关系。