SLURM позволяет заданиям использовать больше процессоров, чем запрошено для запуска

602
remek

Проблема, с которой я сталкиваюсь с SLURM, может быть кратко изложена следующим образом. Рассмотрим скрипт bash, test.shкоторый запрашивает 8 процессоров, но фактически запускает работу с использованием 10 процессоров:

#!/bin/sh #SBATCH --ntasks=8 stress -c 10

На сервере с 32 процессорами, если я запускаю этот скрипт 5 раз sbatch test.sh, 4 из них запускаются сразу, а последний отображается как ожидающий, как показано squeueкомандой:

JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) 5 main test.sh jack PD 0:00 1 (Resources) 1 main test.sh jack R 0:08 1 server 2 main test.sh jack R 0:08 1 server 3 main test.sh jack R 0:05 1 server 4 main test.sh jack R 0:05 1 server

Проблема в том, что эти 4 задания фактически используют 40 процессоров и перегружают систему. Напротив, я бы ожидал, что SLURM либо не запустит задания, которые на самом деле используют больше ресурсов, чем запрашивается пользователем, либо отложит их до тех пор, пока не будет достаточно ресурсов для их запуска.

Некоторые полезные детали о моем slurm.confфайле:

# SCHEDULING  #DefMemPerCPU=0  FastSchedule=1  #MaxMemPerCPU=0  SchedulerType=sched/backfill  SchedulerPort=7321  SelectType=select/cons_res  SelectTypeParameters=CR_CPU # COMPUTE NODES  NodeName=server CPUs=32 RealMemory=10000 State=UNKNOWN  # PARTITIONS  PartitionName=main Nodes=server Default=YES Shared=YES MaxTime=INFINITE State=UP

Я только начинаю с SLURM, и я озадачен этим поведением. Как я могу убедиться, что пользователи моего сервера не запускают задания, которые используют слишком много процессоров? Я прочитал руководство и потратил много времени на поиск информации на форумах, но, к сожалению, я не нашел ничего полезного.

Заранее большое спасибо за вашу помощь!

1

2 ответа на вопрос

1
Carles Fenoy

Slurm не может знать, сколько процессов / потоков собирается создать скрипт. Он может полагаться только на запрашиваемые ресурсы и, следовательно, именно это он использует для планирования заданий.

Наилучшим подходом здесь будет использование любого из подключаемых плагинов в Slurm, чтобы запретить заданиям использовать больше ресурсов, чем запрошено. Эти плагины связывают работу с запрошенным процессором. ( Документация по сходству )

Очевидно, что вы не можете контролировать, сколько процессов / потоков запускает пользователь в своем сценарии, но ограничивая количество ядер, которые может использовать задание, вы уменьшите влияние, которое неконтролируемый пользователь может оказать на задания других пользователей.

Это не помешает вашей системе выглядеть перегруженной, но «плохие» пользователи будут влиять только на себя.

0
Tom

После нашего обсуждения в SO я пытался использовать --exclusiveаргумент для достижения этой цели. Моя архитектура отличается от вашей (у меня есть 7 процессоров, доступных для slurm), но вот что я сделал:

#!/bin/sh #SBATCH --ntasks=2  srun -n 2 --exclusive stress -c 1

а затем работает

sbatch test.sh ; sbatch test.sh ; sbatch test.sh ; sbatch test.sh

дает мне 6 stressпроцессов:

15050 tom 20 0 7308 212 108 R 100.0 0.0 1:47.46 stress  15054 tom 20 0 7308 208 108 R 100.0 0.0 1:47.47 stress  15063 tom 20 0 7308 208 108 R 100.0 0.0 1:47.47 stress  15064 tom 20 0 7308 212 108 R 100.0 0.0 1:47.47 stress  15080 tom 20 0 7308 208 108 R 100.0 0.0 1:47.46 stress  15076 tom 20 0 7308 212 108 R 99.7 0.0 1:47.45 stress

с последним, ожидающим в очереди:

 JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) 2368 Tom test.sh tom PD 0:00 1 (Resources) 2365 Tom test.sh tom R 5:03 1 Tom 2366 Tom test.sh tom R 5:03 1 Tom 2367 Tom test.sh tom R 5:03 1 Tom

Так что в этом случае использование srun -n 2приводит к тому, что один и тот же процесс запускается дважды. То же самое происходит, если я использую

#!/bin/sh #SBATCH --ntasks=2 srun -n 1 --exclusive stress -c 1 & srun -n 1 --exclusive stress -c 1 & srun -n 1 --exclusive stress -c 1 & wait

то есть SLURM знает, что у этого пакетного сценария есть две задачи, поэтому он позволяет двум запускаться одновременно; третий должен «ждать своей очереди».

С другой стороны

#!/bin/sh #SBATCH --ntasks=1 srun -n 1 --exclusive stress -c 2

дает мне поведение, которое вы описываете в своем вопросе.

Не уверен, что это отвечает на 100%, но, возможно, это немного помогает.

Похожие вопросы