Slurm + drake: свободные ресурсы рабочих массивов простаивающих заданий для динамического ветвления

РЕДАКТИРОВАТЬ: заголовок вопроса и теги были скорректированы после того, как было обнаружено, что описанное поведение проистекает не из SLURM, а из пакета R {drake}, который используется в качестве прокси для выполнения заданий массива SLURM.

У меня такая ситуация:

  • Массив заданий Slurm из n=70 с X CPU и Y Mem на задание
  • 120 задач для выполнения
  • Для каждой задачи требуется один и тот же процессор + память, но для завершения требуется разное время

Это приводит к следующей ситуации:

Для задач 71-120 (после выполнения 1 - 70) у меня 50 активистов и 20 простаивающих. Простаивающие рабочие больше не будут работать и просто ждут, пока активные рабочие закончат работу.

Сейчас со временем заканчивают все больше и больше рабочих, и в какой-то момент у меня остается 5 активных и 65 незанятых. Предположим, что для выполнения последних 5 задач требуется некоторое время. В течение этого времени бездействующие рабочие блокируют ресурсы в кластере, а также постоянно выводят следующую информацию в свои соответствующие файлы журналов.

2021-04-03 19:41:41.866282 | > WORKER_WAIT (0.000s wait)
2021-04-03 19:41:41.868709 | waiting 1.70s
2021-04-03 19:41:43.571948 | > WORKER_WAIT (0.000s wait)

[...]

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


r slurm drake-r-package
person pat-s    schedule 04.04.2021    source источник
comment
Разве вы не объединяете здесь две вещи (задания массива slurm и clustermq worker)? Для проверки я бы запустил следующее: (1) sbatch --array=1-2 (sleep script with $SLURM_ARRAY_TASK_ID) (2) clustermq::Q(Sys.sleep, time=c(1,60), n_jobs=2). Остается ли в вашей системе 2-е задание / работник в обоих случаях?   -  person Michael Schubert    schedule 04.04.2021
comment
Может быть! Это работает нормально, то есть первые рабочие завершают работу и освобождают ресурсы, не дожидаясь завершения работы второй. Означает ли это, что проблема не в SLURM и не clustermq, но рабочие ждут из-за отправки через {drake}?   -  person pat-s    schedule 04.04.2021
comment
Похоже, есть ошибка в способе drake определить, нужно ли еще проделать работу. Во всяком случае, не похоже, что причина в трепе.   -  person Michael Schubert    schedule 04.04.2021

Ответы (1)


arrow_upward
0
arrow_downward

Благодаря комментарию @Michael Schubert я обнаружил, что такое поведение возникает при использовании пакета R {drake} и его функции динамического ветвления (статические цели отключаются нормально).

Здесь цель может иметь динамические подцели, которые могут быть вычислены как отдельные задания массива с помощью SLURM. Эти подцели объединяются после того, как все были вычислены. Пока не произойдет этот этап агрегации, все рабочие остаются в состоянии ожидания, в котором они выводят состояние WORKER_WAIT, показанное выше.

Дикие предположения: этого нельзя избежать из-за дизайна динамических целей в {drake}, потому что для агрегирования всех подцелей они должны существовать в первую очередь. Следовательно, отдельные подцели должны храниться / сохраняться во временном состоянии до тех пор, пока не станут доступны все подцели.

Следующий код {drake} R может использоваться в сочетании с кластером SLURM для воспроизведения объясненного поведения:

  list_time = c(30,60),
  test_dynamic = target(
    Sys.sleep(time = list_time),
    dynamic = map(list_time)
  ),
person pat-s    schedule 04.04.2021
comment
Как вы и подозревали, этап очистки динамического ветвления является частью очереди приоритетов, которая предотвращает завершение работы лишних рабочих процессов. Это проектная проблема, которую targets готов исправить, но drake нет. Отслеживание в github.com/ropensci/targets/issues/398. - person landau; 05.04.2021