SGE - QSUB не может отправить задания в режиме -sync

Question

У меня есть сценарий perl, который подготавливает файлы для ввода в двоичную программу и передает выполнение двоичной программы в систему очередей SGE версии 6.2u2.

Задания передаются с параметром -sync yчтобы разрешить родительскому сценарию perl возможность отслеживать состояние отправленных заданий с помощью функции waitpid.

Это также очень полезно, поскольку отправка SIGTERM родительскому сценарию perl передает этот сигнал каждому из дочерних элементов,которые затем направляют этот сигнал на qsub, тем самым изящно завершая все связанные отправленные задания.

Таким образом, очень важно, чтобы я мог отправлять задания с этим параметром -sync y.

К сожалению,Я продолжаю получать следующее сообщение об ошибке:

Unable to initialize environment because of error: range_list containes no elements

Обратите внимание на неправильное написание слов «содержит».Это НЕ опечатка.Это просто показывает, насколько плохо поддерживается эта область кода / сообщения об ошибке.

Попытки отправки, приводящие к этой ошибке, даже не генерируют файлы STDOUT и STDERR *.e{JOBID} и *.o{JOBID}.Отправка только что провалилась.

Поиск в Google по этому сообщению об ошибке приводит только к неразрешенным сообщениям на непонятной доске объявлений.

Эта ошибка даже не возникает надежно.Я могу перезапустить свой сценарий, и те же самые задания не обязательно даже приведут к ошибке.Также не имеет значения, с какого узла я пытаюсь отправить задания.

Я надеюсь, что кто-то здесь сможет это выяснить.

Ответы на любой из этих вопросов, таким образом, решат мою проблему:

1. Сохраняется ли эта ошибка в более поздних версиях SGE?
2. Могу ли я изменить параметры командной строки для qsub, чтобы избежать этого?
3. Какого черта этосообщение об ошибке говорит о?

Answer 1

Наш сайт столкнулся с этой проблемой в SGE 6.2u5.Я разместил несколько вопросов в списке рассылки, но решения не было.До сих пор.

Оказывается, сообщение об ошибке является поддельным.Я обнаружил это, прочитав журналы изменений в репозитории Univa github «open-core».Позже я увидел проблему, упомянутую в Замечаниях к выпуску Son Of Gridengine v8.0.0c.

Вот соответствующие коммиты в репозитории github:

• https://github.com/gridengine/gridengine/commit/b449607972614e4608272d8c0fc6f109d35fbecc
• https://github.com/gridengine/gridengine/commit/a47c32f965111554ec076db1526a6ad62c5bdae5

Что сообщение об ошибке должно сказать, что вы достигли предела количества qsub sync -y заданий в системе.Этот параметр известен как MAX_DYN_EC.По умолчанию в нашей версии было 99, а указанные выше изменения увеличивают это значение по умолчанию до 1000.

Определение MAX_DYN_EC (из справочной страницы sge_conf (5)):

Устанавливает максимальное количество клиентов динамических событий (используемых qsub -sync y и сеансами библиотеки DRMAA API Grid Engine).По умолчанию установлено значение 99. Число клиентов динамических событий не должно превышать половины числа дескрипторов файлов, имеющихся в системе.Количество файловых дескрипторов распределяется между соединениями со всеми хостами exec, всеми клиентами событий и дескрипторами файлов, которые нужны qmaster.

Вы можете проверить, сколько клиентов динамических событий вы используете с помощью следующей команды:

$ qconf -secl | grep qsub | wc -l

Мы добавили MAX_DYN_EC=1000 к qmaster_params через qconf -mconf.Я протестировал отправку сотен qsub -sync y заданий, и мы больше не сталкиваемся с ошибкой range_list.До изменения MAX_DYN_EC это надежно вызвало бы ошибку.

Answer 2

Я нашел решение этой проблемы - или, по крайней мере, обходной путь.

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

Решением этой проблемы было использование команды qrsh с параметром now -n. Это приводит к тому, что задание ведет себя подобно qsub -sync, поскольку мой сценарий может неявно отслеживать, выполняется ли отправленное задание, используя waitpid в экземпляре qrsh.

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

Однако, поскольку я не нашел ничего, даже близкого к решению проблемы qsub -sync, которая была бы столь же функциональной, как эта, позвольте этому посту пройти через все сети к любой своенравной душе, попавшей в мою похожую ситуацию.