У меня есть установка SLURM на одном узле, который также является "узлом входа". Я хотел бы ограничить интерактивное использование ЦП, например вне системы расписания.
Я нашел следующую статью, в которой предлагается использовать для этого 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, в нужную контрольную группу?
Я уже некоторое время бьюсь головой об этой проблеме и, наконец, наткнулся на это решение на stackexchange: https://unix.stackexchange.com/questions/526994/limit-resources-cpu-mem-only-in-ssh-session. Мой ответ ниже адаптирован из этого. Сначала создайте свою ограниченную «интерактивную» контрольную группу в /etc/cgconfig.conf:
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 {}, который позволит учетным записям пользователей помещать себя в эту контрольную группу, используя cgclassify
(Я думаю, но не знаю наверняка, что тогда у них не будет разрешения на удалять сами из этой группы, однако это может быть лазейкой в этом процессе. Для моих целей это потенциальная лазейка, которую я готов принять, учитывая мою пользовательскую базу). Раздел задач {} определяет, кому разрешено назначать задачи контрольной группе. В этом случае мы устанавливаем файл задач как доступный для записи для группы и принадлежащий группе «shelluser». Вам нужно, чтобы ваши пользователи были членами этой группы, иначе ничего из этого не сработает.
Теперь создадим скрипт /etc/profile.d/ssh.sh
. В этом скрипте мы назначим сеансы ssh «интерактивной» контрольной группе, тем самым не позволяя пользователям напрямую перегружать системные ресурсы. Однако иногда вам нужно запускать некоторые вещи в интерактивном режиме, поэтому я разрешил запускать интерактивные сеансы, порождаемые 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, будут помещены в «интерактивную» контрольную группу при входе в систему (при условии, что они являются членами группы unix «shelluser»). В этом случае они будут ограничены 8 Гб и 1/2 одного процессора. Если им нужно иметь возможность запускать вещи напрямую без ограничений, они могут создать экземпляр bash в slurm с помощью
$ srun -p <partition> -c <cpus> --mem=<mem> -t <time> --pty /bin/bash
И он должен работать без ограничений.