Как вы используете SGE для резервирования полных узлов в кластере?
Мне не нужны 2 процессора от одной машины, 3 процессора от другой и так далее. У меня есть четырехъядерный кластер, и я хочу зарезервировать 4 полных машины, каждая из которых имеет 4 слота. Я не могу просто указать, что мне нужно 16 слотов, потому что это не гарантирует, что у меня будет 4 слота на 4 машинах каждый.
Менять правило распределения на FILL_UP недостаточно, потому что, если нет полностью бездействующих машин, SGE просто «заполнит» наименее загруженные машины в максимально возможной степени вместо того, чтобы ждать 4 простаивающих машины и затем планирование задачи.
Есть ли способ сделать это? Есть ли лучшее место, чтобы задать этот вопрос?
Я думаю, что нашел способ, но он, вероятно, не работает на старых SGE, подобных моему. Похоже, в новой версии SGE встроено эксклюзивное планирование.
Другая возможность, которую я рассмотрел, но весьма подверженная ошибкам, - это использовать qlogin вместо qsub и вручную зарезервировать 4 слота на каждой желаемой четырехъядерной машине. Понятно, что автоматизировать это не так уж легко и весело.
Наконец, возможно, это ситуация, когда можно использовать группы хостов. Так, например, создание группы хостов с 4 четырехъядерными машинами в ней, а затем qsubbing к этому конкретному подмножеству очереди, запрашивая количество процессоров, равное максимальному общему количеству в группе. К сожалению, это похоже на жесткое кодирование и имеет много недостатков, например, приходится ждать, пока люди освободят конкретную жестко запрограммированную группу хостов, и требовать изменений, если вы хотите переключиться на 8 вместо 4 машин и т. Д.
Похоже, есть этот скрытый запрос командной строки, который нужно добавить:
-l excl=true
Но вы должны настроить его в свой SGE или OpenGridScheduler, добавив его в список сложных значений (qconf -mc) и включив каждый отдельный хост (qconf -me hostname)
подробности см. по этой ссылке: http://web.archive.org/web/20130706011021/http://docs.oracle.com/cd/E24901_01/doc.62/e21978/management.htm#autoId61
В итоге:
тип:
qconf -mc
и добавьте строку:
exclusive excl BOOL EXCL YES YES 0 1000
затем:
qconf -me <host_name>
и отредактируйте затем строку complex_values, чтобы она читалась:
complex_values exclusive=true
Если у вас уже есть какие-либо комплексные_значения для конкретного хоста, просто разделите их запятыми.
SGE странно с этим, и я не нашел хорошего способа сделать это в общем случае. Одна вещь, которую вы можете сделать, если вы знаете размер памяти узла, который вам нужен, - это выполнить qsub, при этом зарезервировав объем памяти, почти равный полной емкости узла. Это гарантирует, что он захватит систему, на которой больше ничего не работает.
Я пытаюсь делать почти то же самое и ищу идеи. Я думаю, что pe_hostsfile - лучший вариант, но я не являюсь менеджером нашей системы SGE, и файлы hosts не настроены, поэтому мне нужно быстро решить эту проблему. Просто проверил ссылку Настройка эксклюзивного планирования и убедитесь, что для этого также требуются права управления ...
Я думаю, что сценарий-оболочка может это сделать. Я написал однострочную программу bash, чтобы определить количество доступных ядер, оставшихся на машине (см. Ниже). Наша сетка неоднородна: один узел имеет 24 ядра, около 8 и большинство только 4, что немного затрудняет работу.
В любом случае, вот этот однострочный bash.
n_processors=`qhost | awk 'BEGIN{name="'\`hostname\`'"} ; {if($1==name){print int($3)-int($4+0.99)}}'`
Проблема теперь в том, как включить эту переменную bash в директиву предварительной обработки сценария запуска SGE ?? Возможно, я просто предоставлю следующий аргумент в моем сценарии оболочки, поскольку среда pvm поставляется с SGE. Но это не значит, что он настроен ...
#$ -pe pvm 24-4
Страница Sun по управлению параллельными средами довольно полезен, хотя, опять же, инструкции в основном предназначены для администраторов.
Мы устанавливаем правило распределения на количество слотов, доступных на узле (в данном случае 4). Это означает, что вы можете запускать задания только с n * 4 процессорами, но при этом будет достигнут желаемый результат: 16 процессоров будут выделены как 4 узла с 4 процессорами в каждом.
Укажите правило распределения в конфигурации PE как $ pe_slots
Это приведет к тому, что все слоты будут выделены на одном хосте.
Я наконец нашел ответ на это. Сначала я использовал вышеуказанный -l excl=True настройте, как описано выше. Однако это не совсем решает проблему.
Чтобы полностью решить проблему, мне пришлось настроить и дополнительный pe_environment. В моем кластере у нас есть 12 основных узлов. Я буду использовать это в качестве примера.
Я создал дополнительную среду под названием mpich2_12. Вставлено ниже ..
pe_name mpich_12
slots 999
user_lists sge_user
xuser_lists NONE
start_proc_args /opt/gridengine/mpi/startmpi.sh -catch_rsh $pe_hostfile
stop_proc_args /opt/gridengine/mpi/stopmpi.sh
allocation_rule 12
control_slaves TRUE
job_is_first_task FALSE
urgency_slots min
accounting_summary TRUE
Обратите внимание, что для параметра allocation_rule установлено значение 12, это означает, что задание ДОЛЖНО использовать 12 ядер на узле. Если вы отправите задание, запрашивающее 48 процессоров, оно будет ждать и захватить 4 ПОЛНЫХ узла, когда они станут доступны.
Я все еще использую -l excl=True вариант, но я подозреваю, что сейчас это не имеет значения.
Если у меня есть задания, для которых требуется только один процессор (а я это делаю), я отправляю их в ту же очередь, но без -l exel=True вариант, и я использую свой оригинальный pe_environment который имеет allocation_rule = 'fillup' Любое задание, представленное в среде mpich_12, будет ждать, пока не освободятся все узлы. Мой кластер теперь работает намного лучше.