PBS/ приоритет крутящего момента против приоритета программы MPI
У нас есть Кластер, выполняющий разные задачи. Это компьютерное моделирование с использованием планировщика Torque. У нас также есть интерактивная симуляция, которая также нуждается в полной вычислительной мощности. Интерактивное моделирование - это программа OpenMPI, запускающая процессы на каждом узле.
Поэтому мы хотим иметь следующее: Если интерактивное моделирование запущено, все задания pbs должны быть перенесены в фоновый режим, освобождая рабочую нагрузку для интерактивного моделирования.
Возможно ли это даже с этими двумя различными схемами распараллеливания?
Я попробовал следующее: я назначил пользователям очереди крутящего момента более низкий приоритет, добавив в /etc/security/limits.conf строку
user hard priority 10
для каждого пользователя на каждом узле. Но это игнорируется планировщиком, задания pbs по-прежнему получают значение 0.
Кластер работает с CentOS.
Влияет ли опция приоритета qsub -p на приоритет соответствующих заданий или это только для планировщика?
Я надеюсь, что кто-то здесь имеет опыт с правильной настройкой системы массового обслуживания.
1 ответ
-p вариант в qsub влияет только на приоритет задания в очереди. Если вы хотите запустить процессы с более низким приоритетом или в Unix/Linux с более высоким приятным значением, вы можете использовать qsub -l nice=19 чтобы начать процессы. В зависимости от используемой реализации MPI и приложения это все еще может не работать, но должно работать в целом.
Что ж, этот метод только скажет ОС выделять меньше времени центрального процессора / планировщика для этого приложения, но весьма вероятно, что это приведет к перегружению интерактивного задания, выполняемого с точностью 0. Не забывать объем памяти, который может не удовлетворять потребности одновременной работы.
Обычно вы хотите приостановить работу, чтобы освободить ресурсы в кластере, что приводит к собственным проблемам. Одним из подходов может быть остановка процессов с SIGSTOP и перезапустите их SIGCONT снова. Я не работал с Torque в течение нескольких лет, но я думаю, что должен быть способ указать свой собственный сценарий, когда работа приостановлена. Посмотрите также на упреждения на ваши дальнейшие исследования.
К сожалению, этот подход также может работать некорректно с MPI и зависит от реализации MPI. Таким образом, вы также должны прочитать о возможностях версии MPI, которую вы используете. Кроме того, это также не освобождает ваши ресурсы памяти, и узел может начать обмен, или OOM убивает ваши задания.
Обычно вы хотите проверить свои рабочие места, что позволяет действительно завершить процессы и освободить ресурсы. Эта контрольная точка, возможно, лучше всего поддерживается в приложении, выписывая промежуточные результаты, из которых вы можете перезапустить. Существуют также подходы к контрольным точкам, которые не зависят от приложения, но, насколько я знаю, они также не работают надежно. Просто используйте поисковую систему по вашему выбору и найдите контрольную точку mpi.
Можно также рассмотреть возможность отменить задание MPI и потребовать его начать позже. В зависимости от работы и принятия пользователя.
Вы также можете оставить один или два узла для интерактивной работы в рабочее время, если вы можете себе это позволить или если потребность в бесплатных ресурсах для интерактивных заданий слишком высока.
Другим важным моментом может быть изменение планировщика на maui, так как планировщик крутящего момента по умолчанию очень ограничен в настройке расширенного планирования.