为了解决抢占 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