我在单个节点上设置了 SLURM,该节点也是“登录节点”。我想限制交互式 CPU 使用率,例如在调度系统之外。
我发现以下文章建议为此使用 cgroups:https://rolk.github.io/2015/04/20/slurm-cluster
我认为这是完美的,并按以下方式进行设置:
/etc/cgconfig.conf
:
group root {
cpu {}
}
group interactive {
cpu {
cpu.cfs_period_us=100000;
cpu.cfs_quota_us=400000;
}
}
group batch {
cpu {}
}
/etc/cgrules.conf
:
root cpu root
slurm cpu batch
* cpu interactive
我习惯cgrulesengd
运用这些规则。
问题是,使用 SLURM 正确排队的任务也会在相应用户自己的用户下运行(而不是slurm
),因此它们会被放入interactive
cgroup 中。当然,这不是我想要的。我假设我所遵循的文章期望任务会在用户下运行slurm
。
有没有办法将 SLURM 运行的所有任务放入正确的 cgroup 中?
答案1
我已经为这个问题苦苦思索了一段时间了,最后在 stackexchange 上找到了这个解决方案:https://unix.stackexchange.com/questions/526994/limit-resources-cpu-mem-only-in-ssh-session。以下是我根据该内容改编的回答。首先,在 /etc/cgconfig.conf 中创建有限的“交互式” cgroup:
group interactive {
perm {
admin {
uid=root;
gid=root;
}
task {
uid=root;
gid=shelluser;
fperm=775;
}
}
cpu {
cpu.cfs_period_us = "1000000";
cpu.cfs_quota_us = "500000";
}
memory {
memory.limit_in_bytes = "8G";
memory.memsw.limit_in_bytes = "8G";
}
}
我们添加了 perm{} 子部分,这将使用户帐户能够使用以下方式将自己放入此 cgroup 中cgclassify
(我认为,但不确定,他们是否无权这样做)消除他们可以自己从该组中退出,但这可能是此过程中的一个漏洞。就我的目的而言,考虑到我的用户群,我愿意接受这个潜在的漏洞)。task{} 部分规定谁可以向 cgroup 分配任务。在本例中,我们将任务文件设置为组可写并由“shelluser”组拥有。您需要您的用户成为此组的成员,否则这一切都将不起作用。
现在,创建脚本/etc/profile.d/ssh.sh
。在此脚本中,我们将 ssh 会话分配给“交互式”cgroup,从而防止用户直接占用系统资源。但是,有时您确实需要以交互方式运行某些内容,因此我允许 slurm 生成的交互式会话不受限制地运行。同样,我这样做的方式几乎肯定会被聪明的用户利用,但考虑到我们的用户,我愿意接受这种风险:
# check if user is in an SSH session and *hasn't* been spawned by slurm
if [[ -n $SSH_CONNECTION ]] && [[ -z $SLURM_JOBID ]]; then
# get the shell pid
SESSIONPID=$$
# attach the shell to the relevant cgroup
cgclassify -g memory,cpu:interactive $SESSIONPID
# now everything spawned by this shell should be in this cgroup
fi
通过 SSH 登录的用户将在登录时被置于“交互式”cgroup 中(前提是他们是“shelluser”unix 组的成员)。在这种情况下,他们将被限制为 8G 和 1/2 个 CPU。如果他们需要能够不受限制地直接运行东西,他们可以使用以下命令在 slurm 下生成一个 bash 实例
$ srun -p <partition> -c <cpus> --mem=<mem> -t <time> --pty /bin/bash
并且它应该不受限制地运行。