Материал из eSyr's wiki.

Версия 20:55, 21 марта 2008

С прошлого раза: в случае, когда провайдер не пускает, ключ -R (а не -L). В блюгене трёхмерный тор, а не 6-мерный.

Постановка задач пользователей в очередь

Есть некий пользователь, есть некая многопроцессорная система, которая пользователю выглядится как некий чёрный ящик, про который ему известно, что там много процессоров, какой-то объём памяти. Пользователь написал/взял где-то зашибись замечательную программу, которая требует себе значительное количество ресурсов. Обычно количество ресурсов можно для соотв. программы варьировать. Вопрос к общественности: какие программе могут понадобиться ресурсы? При этом, мы предоставляенм набор чёрных ящиков на определённое время. Ресурсы:

• Количество процессоров
• Количество памяти
  • Физической на узел кластера
  • Виртуальной на узел кластера
  • Размер файла подкачки на узел кластера
  • Суммарное ограничение на используемую память
• Ограничение на время. Вопрос: какое время?
  • Астрономическое время --- с 15 марта по 15 мая
  • Использовать не больше, чем 300 часов суммарного процессорного времени
  • Использовать не более, чем 300 часов астрономического времени
• Сетевой трафик в случае GRID
• Лицензионные ограничения

Жизненный цикл задачи пользователя

Есть у полььзователя терминал, он говорит,что хочет запустить задачу и указывает ограничения. У него есть приложение клиентское, которое участвует в постановке задачу в очередь. Этот терминал коннектится к серверу очередей. ДАльше сервер очредей занимается тем, что анализирует ограничения. Если с ограничениями всё хорошо (это значит,что пользователь попросил что-то, что по объёму меньше, чем предоставляет многопроцессорная система). После этого проверяются пользовательские ограничения. В некоторых ситуациях он меняется со временем. Потом залдача ставится в очередь. Поставленная задача движется в очереди до момента своего назначения. Перед постановкой задачи в очередь анализируется такая штука, как количество одоновременно поставленных задач в очереди. Про задачу известно:

• Объём ресурсов
• Пользователь
• Статистика по запускам
• Ситуация на много процессорной системе
• У задачи, поставленной в очередь, есть статус

Приоритеты:

• Приоритет адачи
• Приоритет пользователя

Чего добиться:

• Справедливость по отношению к пользователями
• Эффективное использование доступных ресурсов

Причём первое более важное, чем второе. Кроме того, система очередей должна гарантировать, что задача когда-нибудь выполнится.

Наконец, случился момент назначения, задача распределилась по какому-то числу процессоров. Что с этой задачей может произойти дальше?

• Задача запустилась и работает
• Приостановлена
• Отработка контрольной точки
• Стартует задача
• Перемещаемая задача
• Задача может завершаться. Сама или принудительно, по исчерпании ресурсов.

Конкретный пример

Есть несколько известных в текущий момент систем очередей:

• LoadLeveler
• PBS, torque + maui, moab + maui, Sun Grid Engine

У этих двух систем разные соглашения по именованию утилей по запуску задач. У LL --- llsubmit, у остальных --- qsub

• cleo
• run_mvs --- МСЦ

Прочая информация про задачу

• Файл ввовывод задача
• Оповещение о запуске
• Оповещение о завершении
• Зарезервировать определённые узлы на определённое время, но при этом ничего тпасм не запускать

Примеры

пример файла с паспортом задачи

#! /bin/sh
#PBS -l wtime=1:00:00
#PBS -l mem=400mb
#PBS -l ncpus=100
./my_job

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

Ключи:

• -h --- захолдить сразу после запуска
• -N --- указать имя задачи
• -o --- поток вывода
• -q --- имя очереди
• -s --- шелл
• -с --- интервал для чекпоинта
• -e --- текущий каталог для задачи

Какие параметры на ограничения можно выставить (синтаксис: -l ограничение=параметр, через запятую, если несколько)

• arch --- Архитектура
• cput --- объём процессорного времени
• mem --- объём памяти
• ncpus --- количество процессоров
• nice --- приоритет юниксовый во время выполнения
• nodes --- число и тип необходимых задаче узлов
• pcput
• pmem
• pvmem --- число виртуальной памяти, необх. задаче
• resc --- позволяет при помощи некоего логического языка выставить ограничения на всё, что перечислено
• software --- указывает лицензии
• walltime --- астрономическое время выполнения задачи

Групповой учёт заданий

• Запуск одной задачи н раз, желательно подряд. Тогда эта задача отдельно планируется от всех остальных с учётом этого факта
• Сцепленные задачи. Это когда есть набор задач, и для исполнения очередной задачи нужно исполнить неоке количество предыдущих задач. В общем случае это граф задач, где сказано, как эти задачи зависят друг от друга. В случае с LL это job stack, и это планируется отдельно. Указывается это всё в паспорте задач примерно в таком ключе: #job name. В этом случае оно будет другое. И на соотв шаге можно указать, что очередной job step зависит от соответствующих имён: #job step job name 1, job name 2, job name 3...