эффективность в ограничении количества параллельных заданий в жире - PullRequest
Новая
       37

эффективность в ограничении количества параллельных заданий в жире

0 голосов
/ 20 января 2019

Мой вопрос основан на ЭТОМ вопросе.

Я должен рассмотреть возможность использования --array=0-60000%200, чтобы ограничить число параллельных заданий до 200 в slurm. Мне кажется, что на обед на новую работу уходит до минуты каждый раз, когда старая работа заканчивается. Учитывая количество заданий, которые я планирую выполнить, я мог бы тратить на это много времени.

Я написал «наиболее вероятную» очень неэффективную альтернативу, состоящую из сценария, который запускает задания, проверяет количество заданий в очереди и добавляет задания, если я все еще ниже максимального допустимого числа заданий, и пока Я достиг максимального числа параллельных заданий, сплю 5 секунд, следующим образом: 

#!/bin/bash

# iterate procedure $1 times.  $1=60000
for ((i=0;i<=$1;i++))
do
    # wait until any queued process is finished
    q=$(squeue -u myuserName | wc -l) #I don't care about +/-1 lines (e.g. title)
    while [ $q -gt 200 ] #max number of parallel jobs set to 200
    do
        sleep 5
        q=$(squeue -u myuserName | wc -l)
    done
    # run the job with sbatch
    sbatch...  
done

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

Спасибо.

1 Ответ

0 голосов
/ 22 января 2019

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

При использовании вашего подхода ваши задания также теряют приоритет: каждый раз, когда одно из ваших заданий заканчивается, вы запускаете новое, и это новое задание будет последним в очереди. Кроме того, SLURM придется управлять несколькими сотнями независимых заданий, а не только теми, на которые приходится 60000, что вам нужно.

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

...