Запуск GNU Parallel на 2 и более узлах с помощником планировщика Slurm

Я пытаюсь распределить независимые запуски процесса, используя GNU Parallel на HPC, который использует менеджер заданий Slurm. Кратко, вот как настроен анализ данных:

Скрипт#1: myCommands

./myscript --input infile.txt --setting 1 --output out1
./myscript --input infile.txt --setting 2 --output out2
./myscript --input infile.txt --setting 3 --output out3
./myscript --input infile.txt --setting 4 --output out4

Скрипт#2: run.sh

#SBATCH --time=00:02:00
#SBATCH --nodes=2
#SBATCH --cpus-per-task=2

cat myCommands | parallel -j 4

Это работает, однако используется только один узел. Два ядра на этом узле делятся на 4 потока, чтобы обеспечить 4 задания, как это требуется в parallel. Это нежелательно.

Мои поиски показывают, что мне понадобится nodefile и sshloginfile, чтобы этого достичь, но я не нашел примеров в Интернете, которые работали бы с Slurm, только с системой PBS.

Как мне сделать так, чтобы скрипт (1) использовал оба узла и (2) не разделял ядра на потоки?

Вы можете сделать это с помощью round robin srun (что-то вроде):

jobs=({1..4})
nodes=($(scontrol show hostname $SLURM_NODELIST))
for ((n = 0; n < ${#jobs[@]}; n++)); do
  index=$(expr $n % ${#nodes[@]})
  srun --nodes=1 --ntasks=1 --nodelist=${nodes[$index]} \
       --exclusive ./myscript --input infile.txt \
       --setting $n --output out$n &
done
wait

Я предполагаю, что --cpus-per-task=2 будет передано srun. Дайте знать, если у вас возникнут проблемы. Я сегодня утром немного экспериментировал с parallel, но не вижу, как напрямую решить эту проблему. Кроме того, я обнаружил, что если вы scancel задачу, которая содержит задания GNU parallel, запущенные процессы не завершатся, если вы не используете srun.

В настоящее время я использую GNU Parallel, чтобы фактически просто “паковать” мои задания на удаленный кластер:

Вот фрагмент с удаленным именем скрипта:

parallel --colsep '\t' \
         --shuf \
         --jobs=25% \
         --delay=1s \
         ssh -q ${remote} \
         sbatch --chdir="${remote_dir}" \
         --job-name="my-job-name-{1}-{2}-{4}-{5}_{6}" \
         --output="${OUTPUT_PREFIX}/joblogs/%x.out" \
         --error="${OUTPUT_PREFIX}/joblogs/%x.err" \
         my-job.sh \
         "${OUTPUT_PREFIX}/" "{1}" "{2}" "{4}" "{3}" "{5}" "{6}" \
         :::: "${COMPARISONS}" \
         :::: "${REPORTS}" \
         :::: "${METHODS}"

Каждая из переменных ${COMPARISONS}, ${REPORTS} и ${METHODS} является табуляционно разделенными файлами, которые затем передаются в sbatch. По сути, это использует декартово произведение аргументов от parallel, чтобы отправить различные вариации, а затем управление заданиями передается SLURM, а не parallel.

my-job.sh – это что-то вроде следующего:

#!/usr/bin/env bash

#SBATCH -N 1
#SBATCH -n 1
#SBATCH -c 4
#SBATCH -t 0-01:00:00

exec ~/bin/job.bin $@

Если ваша очередь это поддерживает, вам не нужно вручную указывать узлы (если нет какой-либо другой причины делать это).

Надеюсь, это поможет. На самом деле я пришел искать способ замедлить это, чтобы не перегружать диспетчер (я уже отправляю достаточно заданий, что сам себе создаю очередь, пока задания не начнут завершаться, большинство заданий занимают от нескольких секунд до 10 минут). У parallel есть опция --delay, которая может быть полезна при отправке сотен заданий.

Если вы хотите, чтобы parallel использовался в вашей изначально запущенной скрипте и чтобы он запускал задания в SLURM, вы можете, вероятно, лучше адаптировать ответ @barrymoo с помощью sbatch и устранить список узлов (снова, если нет особого требования использовать только часть доступных вам узлов; большинство HPC спроектированы так, чтобы быть максимально справедливыми между узлами в их соответствующих очередях).