Notes on Slurm

发表于 | 更新于 | 分类于

为了解决抢占 GPU 资源的问题，最近 DIKU 开始推行 Slurm。

Slurm 任务调度工具（前身为极简 Linux 资源管理工具，英文：Simple Linux Utility for Resource Management，取首字母，简写为 SLURM），或 Slurm，是一个用于 Linux 和 Unix 内核系统的免费、开源的任务调度工具，被世界范围内的超级计算机和计算机群广泛采用。它提供了三个关键功能。第一，为用户分配一定时间的专享或非专享的资源 (计算机节点)，以供用户执行工作。第二，它提供了一个框架，用于启动、执行、监测在节点上运行着的任务 (通常是并行的任务，例如 MPI)，第三，为任务队列合理地分配资源。

大约 60％的 500 强超级计算机上都运行着 Slurm，包括 2016 年前世界上最快的计算机天河 - 2。

Slurm 使用基于 Hilbert 曲线调度或肥胖 网络拓扑结构的最适算法，以便优化并行计算机中的任务分配。

在用了 Slurm 之后，原来从 Local Machine 直接登录 GPU Server 这样的两层结构，变成了
Local Machine -> Gate -> Slurm -> GPU Server 这样的四层结构。以前的话，直接在 Local Machine 上登录 GPU Server，但 GPU 资源会一直被霸占或者什么的，引入 Slurm 就是为了更好地让大家利用资源。现在的话，必须先从 Local Machine ssh 登录 Gate Server，然后再从 Gate Server ssh 登录 Slurm，我们能登陆的就到这里了，在 Slurm 服务器上把 任务 提交，Slurm 会自动给分配计算资源，运行完后，会有类似 slurm-xxxxxx.out 这样的格式的输出，就相当于程序运行的结果

具体可以看 http://image.diku.dk/mediawiki/index.php/Slurm_Cluster

使用

Local Machine -> Gate Server

在 .ssh/config 中添加如下内容，记得把 换成 KU ID

1
2
3
4
5
6
7
8
9
10
Host gate-diku
    HostName ssh-diku-image.science.ku.dk
    User <kuid>
Host cluster
    HostName a00552
    User <kuid>
    ProxyCommand ssh -q -W %h:%p gate-diku
Host gpu*-diku-image
    User <kuid>
    ProxyCommand ssh -q -W %h:%p gate-diku

然后运行 ssh gate-diku 就ssh 登录到了 Gate Server 上去了

Gate Server -> Slurm Server

登录 Gate Server 后同样的，vim .ssh/config 添加一样的内容，

1
2
3
4
5
6
7
8
9
10
Host gate-diku
    HostName ssh-diku-image.science.ku.dk
    User <kuid>
Host cluster
    HostName a00552
    User <kuid>
    ProxyCommand ssh -q -W %h:%p gate-diku
Host gpu*-diku-image
    User <kuid>
    ProxyCommand ssh -q -W %h:%p gate-diku

然后运行 ssh cluster 就ssh 登录到了 Slurm Server 上去了。事实上，是可以直接从 Local Machine SSH 登录到 Cluster 的。

Slurm Server -> GPU Server

这一步，我们并不被允许直接登录 GPU Server 但是我们可以用 sbatch XXXX.sh 这样的命令提交我们的请求，也就是说我们要在 XXXX.sh 里面指定好我们要什么资源，要运行什么程序

以 Start a Job on the GPU cluster 为例

1
2
3
4
5
6
7
8
9
10
11
12
13
#!/bin/bash
# normal cpu stuff: allocate cpus, memory
#SBATCH --ntasks=1 --cpus-per-task=10 --mem=6000M
# we run on the gpu partition and we allocate 2 titanx gpus
#SBATCH -p gpu --gres=gpu:titanx:2
#We expect that our program should not run langer than 4 hours
#Note that a program will be killed once it exceeds this time!
#SBATCH --time=4:00:00

#your script, in this case: write the hostname and the ids of the chosen gpus.
hostname
echo $CUDA_VISIBLE_DEVICES
python3 yourScript.py

总体的原则是 需要的资源越少，越会被提前安排。

--cpus-per-task=10 指定需要多少个 CPU，--gres=gpu:titanx:2 指定需要什么型号的 GPU，要几个，可以 --gres=gpu:1 即不一定非要 titanx，gpu 只要一个，但最好还是制定一下 GPU，因为里面有一个很老的 GTX 450，且不在列表上，被分配到这个上去就坑了。

#SBATCH --time=4:00:00 指定需要多长时间，这里是 4 hour，改少一点，和实际相符，如果太长的也会被往后排；太短超过了时间很可能会被中止。

注意 hostname 就保持不变，不要真改成什么 gpu01-diku-image 这种

查看

查看排队和运行情况

squeue | grep <kuid>

如果要看实时的输出

watch -n 1 "squeue | grep <kuid>"

实时查看 log file 的变动

tail -n 1 -f slurm-xxxxxx.out

上面的 1 都是指 1 秒。

问题

Check failed: err == CUDNN_STATUS_SUCCESS (6 vs. 0) CUDNN_STATUS_ARCH_MISMATCH

这个原因是因为 GPU 太老的问题，程序被分配到很老的 GPU 上去了。在 DIKU 的 cluster 中有一个很老的 GPU，解决方法就是在 sbatch 的 shell 文件中指定好新的 GPU。

如果您觉得我的文章对您有所帮助，不妨小额捐助一下，您的鼓励是我长期坚持的动力。

Alipay_Middle Wechat_Middle