PBS обеспечивает различные процессы, планирующие, какие задания нужно
передавать на исполнение. Это гибкий механизм, с помощью которого можно
реализовать широкое множество стратегий. Планировщик использует стандарты
PBS API для коммуникаций с Сервером и дополнительный API (Прикладной
Программный Интерфейс) для коммуникаций с монитором ресурсов, pbs_mom.
Если предлагаемые планировщики окажутся недостаточными для нужд вашего сайта,
можно реализовать замещающий их Планировщик, используя приданные API, которые
обеспечат желаемую политику.
Первая версия пакетной системы, NQS, и многие другие пакетные системы
используют различные, основанные на очереди способы управления заданиями.
Очереди включаются и выключаются для управления порядком заданий во времени или
ограничения количества заданий в очереди.
В то время как PBS поддерживает многие очереди, и очереди имеют атрибуты
"планирования заданий", используемые другими пакетными системами, Сервер PBS
сам по себе не исполняет задания. Он только обеспечивает соблюдение всех
ограничений, налагаемых атрибутами очереди. В действительности, Сервер
с радостью будет исполнять доверенное ему задание из остановленной очереди с
нулевым лимитом времени на выполнение заданий, если ему прикажут это сделать.
Приказ может поступить от оператора, администратора или Планировщика.
Планировщик фактически является только клиентом с административными
привилегиями.
Если вы предпочтете реализовать на своем сайте собственную политику
планирования, используя кратную очередь --- схему базисного контроля очередей,
вы можете это сделать. Сервер и атрибуты очередей, используемые для управления
планированием исполнения заданий, могут настраиваться клиентами с привилегиями,
такими как qmgr(8B), или одним из ваших программистов. Но фактически управление
находится в руках Планировщика, а не Сервера. Планировщик должен
контролировать состояние Сервера и очередей, также как и заданий, определяя
ввод в действие Сервера и управляя очередями. Он должен использовать установки
параметров контроля при принятии своих решений.
Другой подход есть подход с точки зрения "единого пула", когда все задания
находятся в одном пуле (в единой очереди). Планировщик оценивает каждое
задание по своим меркам и решает, какое из них (или никакое) запустить.
В стратегии могут учитывается ряд факторов, такие как время дня, загрузка
системы, размер задания и т.д. Порядок заданий в очереди можно не
рассматривать. Разработчики PBS полагают, что такой подход предпочтительнее по
двум причинам:
1. Пользователи не подвергаются искушению лгать в их требованиях,
чтобы "выиграть" в политике очередей.
2. Планирование может осуществляться в рамках полного множества
текущих заданий с целью лучшего использования имеющихся ресурсов.
При разработке политики планирования может оказаться важным понимание того,
когда и как взаимодействуют Сервер и Планировщик. Сервер всегда инициирует
цикл планирования. Когда атрибут sheduling активизируется внутри Сервера,
Сервер открывает связь с Планировщиком и выдает команду, указывающую причину
для планировочного цикла. Причины или события, по которым запускается этот
цикл, следующие:
- Какое-то задание впервые поступает на исполнение. Это может быть новое
задание в исполнительной очереди или задание из исполнительской
очереди, которое только что изменило состояние задержки или ожидания
на очередное (queued). [ SCH_SCHEDULE_NEW ]
- Выполняемое задание кончается (terminates). [ SCH_SCHEDULE_TERM ]
- Исчерпан временной интервал после предыдущего цикла, запущенного по
атрибуту Сервера schedule_iteration. [ SCH_SCHEDULE_TIME ]
- Серверский атрибут scheduling установлен или переустановлен на true.
Если это значение есть true, даже если прошлое значение было также true,
Планировщик выполнял цикл. Это дает оператору/администратору средство
включения цикла планирования. [ SCH_SCHEDULE_CMD ]
- Если Планировщик выполнил цикл и на исполнение затребовано одно и только
одно задание, то Сервер вновь запускает цикл планирования. На первый
взгляд это непонятно. Но это сделано для "упрощения" Планировщика.
Планировщик должен беспокоиться о выборе одного наилучшего задания за
цикл. Если и другие задания также могут выполняться, он теперь получает
возможность выбрать
следующее задание. Независимо от того, может ли Планировщик запустить
ни одно или больше чем одно задание, ясно, что его не нужно вызывать
Sheduler run none or more than one job in a cycle it is
снова до тех пор, пока условия не изменятся и одно из перечисленных
выше событий не вызовет следующий цикл. [ SCH_SCHEDULE_RECYC ]
- Если Сервер только что запущен, первый планировочный цикл запускается
отдельно. [ SCH_SCHEDULE_FIRST ]
Если Сервер вступил в контакт с Планировщиком и передал ему причину контакта,
то Планировщик становится привилегированным клиентом Сервера. Как таковой,
он может скомандовать Серверу выполнить любое действие, разрешенное менеджеру.
Когда Планировщик закончит все свои действия в очередном цикле, он прекратит
связь с Сервером. Пока связь действовала, Сервер не может пытаться открыть
новую связь.
Заметим, что Сервер вступает в контакт с Планировщиком для начала нового
цикла планирования только тогда, когда атрибут sheduling становится активным
в Сервере. Он становится активным при установке на true и "qstat-B" покажет
статус Сервера как Active. Если scheduling установлен на false, то Сервер
не вступит в контакт с Планировщиком и статус Сервера показывается как Idle.
При запуске Сервер восстановит значение scheduling таким, каким оно было при
закрытии Сервера. Значение может изменяться по двум причинам: параметр -a
в командной строке pbs_server или установкой scheduling на true или false
по qmgr.
Необходимо уяснить одно обстоятельство относительно упорядочивания заданий:
Очереди "есть" и "не есть" типа FIFO.
Это значит, что хотя задания упорядочиваются как первый вошел -- первый вышел
в Сервере и в каждой очереди, этот факт НЕ влечет за собой, что выполнение их
в таком порядке предписывается, требуется или даже только желательно.
Решение остается полностью в компетенции политики сайта и ее реализации.
Сервер поддерживает порядок при перезапусках исключительно в помощь сайтам,
которые хотят поддерживать порядок FIFO в какой-нибудь форме.
Предоставляемый Планировщик BaSL использует Cи-подобный процедурный язык
для описания политики планирования. Он содержит несколько конструкций и
при определенных функций, облегчающих реализацию принятых принципов планирования.
Информация о Сервере PBS, очередях, которыми он обладает, о заданиях в каждой
очереди и о вычислительных узлах, где задания могут исполняться, доступны
через типы данных BaSL, такие как Server, Que, Job, CNode, Set Server,
Set Que, Set Job и Set CNode.
Идея состоит в том, что сайт сначала должен написать функцию (содержащую
алгорифм планирования), называемую sched_main() (и все вспомогательные функции
для нее), используя конструкции BaSL, и затем перевести эти функции на Си,
используя компилятор basl2c, который привяжет также Главную программу к
результирующему коду. Эта главная программа производит общую инициализацию
и сервисные средства, такие как установка локальных соединений (socket) для
коммуникаций с Сервером, исполняемым на той же машине, установку каталогов в
в каталоге priv, открытие регистрационных файлов и конфигурационного файла
(если нужен), установку замков, развитие потомков в демонов, инициализацию
планировочного цикла (то есть получение атрибутов узла, статических по
природе), установку сигналов обработчиков, выполнение глобальных
инициализирующих операторов присваивания, определенных автором Планировщика,
и финальное вхождение в цикл ожидания команды планирования от Сервера.
Имя результирующего кода есть pbs_sched.c.
Когда Сервер посылает Планировщику соответствующую команду планирования
{ SCH_SCHEDULE_NEW , SCH_SCHEDULE_TERM ,
SCH_SCHEDULE_TIME , SCH_SCHEDULE_RECYC ,
SCH_SCHEDULE_CMD , SCH_SCHEDULE_FIRST }, Планировщик просыпается и
получает информацию о Сервере(рах), заданиях, очередях, вычислительных хостах
и затем вызывает sched_main(). Список серверов, вычислительных хостов,
запросов хостов к хостовским Mom указаны в конфигурационном файле Планировщика.
Глобальные переменные, определенные в программе BaSL, сохраняют свои значения
между планировочными циклами, а локальные переменные -- нет.
Планировщик на базе Tcl использует базисный интерпретатор Tcl с некоторыми
дополнительными командами для коммуникаций с Сервером PBS и Монитором
ресурсов. Стратегия планирования определяется сценарием, написанным на Tcl.
Некоторое количество примеров сценариев приведены в исходной каталоге
src/scheduler.tcl/sample_scripts.
Планировщик на базе Tcl в самых общих чертах действует следующим образом.
1. После старта Планировщик читает инициализирующий сценарий (если он указан
параметром -i) и выполняет его. Затем тело сценария переписывается в память.
Это файл, который выполняется каждый раз, когда от Сервера приходит
команда "schedule". Затем он опять ожидает команду "schedule".
2. При получении команды выполняется тело сценария. Сценарий не
подвергается никакой специальной обработке, кроме обеспечения связи с
сервером. Типовой сценарий нуждается в получении от Сервера информации о
заданиях-кандидатах на исполнение с помощью pbsselstat или pbsstatjob. Другая
информация от Монитора ресурсов получается открытием связи по команде
openrm и соответствующих запросов по addreq and получением результатов по
getreq. Связи с Монитором ресурсов должны быть закрыты явно с помощью closerm,
или Планировщик выйдет в конце концов из файловых дескрипторов. Когда принято
решение выполнять задание, нужно вызвать pbsrunjob.
3. Когда выполнение сценария завершится, Планировщик закроет TCP/IP связь
с Сервером.
Планировщик не перезапускает интерпретатор Tcl в каждом цикле. Это дает
возможность переносить информацию от одного цикла к следующему. Это также
может вызвать трудности, если переменные
не инициализируются или не устанавливаются при начале сценария, когда они не
обязаны содержать позже какую-то информацию.
Сценарий часто пользуется средней загрузкой системы. Это число получается от
ядра системы с помощью pbs_mom. Большинство систем сглаживают значение средней
загрузки по периоду времени. Если один цикл планирования запускает одно или
более заданий, а следующий цикл начинается быстро, то влияние вновь
запущенного задания, вероятно, не отразится на средней загрузке. Это может
привести к скачку вверх средней нагрузки, особенно при первом старте
пакетной системы. Также при окончании задания задержка в снижении средней
загрузки может отсрочить планирование дополнительных заданий.
Планировщик перенаправляет вывод с "stdout" и "stderr" в файл. Это позволяет
легко генерировать отладочный выход для проверки того, что делает ваш
сценарий. Рекомендуется воспользоваться этим свойством, если вы не уверены, что
ваш сценарий работает правильно.
Лучший совет состоит в изучении примеров, находящихся в
src/scheduler.tcl/sample_scripts. Затем, если вы изменили или написали
сценарий тела планировщика и, возможно, сценарий инициализации, поместите их в
каталог {PBS_HOME}/sched_priv и вызовите Планировщик, напечатав
{sbindir}/pbs_sched [-b body_script] [-i init_script]"
См. также указания в pbs_sched_tcl(8) man page.
Планировщик на базе Си по структуре и действиям подобен Планировщику Tcl
за исключением того, что вместо сценариев Tcl используются функции Си.
1. После старта Планировщик вызывает schedinit(argc, argv) только один раз,
чтобы инициализировать то, что нужно инициализировать.
2. Когда получена команда на планирование, начинает действовать функция
schedule(cmd, connector), которая и проводит все планирование.
3. После возвращения в основной цикл связь с сервером закрывается.
Несколько рабочих примеров кода планировщика находятся в подкаталоге примеров.
В следующих разделах обсуждаются некоторые из образцов планировщиков, в том
числе стандартный планировщик fifo. Исходные коды образцов находятся в
src/scheduler.cc/samples под именами типа Scheduler, например
src/scheduler.cc/samples/fifo.
Этот планировщик действует по нескольким простым принципам. Он способен
сортировать задания несколькими различными способами в добавок к порядку
FIFO. Он может также сортировать по пользовательским или групповым
приоритетам. Главным образом, он должен служить отправной точкой при написании
реального планировщика. Большая часть его кода написана так, чтобы было легко
вносить в него изменения и добавления. Справьтесь в IDS, где содержится
достаточно подробное описание кода.
Доставляемый Планировщик fifo Scheduler конфигурируется со следующими
возможностями (см. файл PBS_HOME/sched_priv/sched_config:
- Все задания в одной из очередей проверяются на возможность их
исполнения перед переходом к следующей очереди.
- Очереди сортируются по их приоритетам.
- Задания в пределах каждой очереди сортируются по затребованному
времени процессора. Короткие задания располагаются в ее начале.
- Задания, которые томятся в очереди более одного дня, считаются
страдающими и особые меры применяются для их исполнения.
- Каждая очередь, имя которой начинается на "ded" , рассматривается как
специализированная временная очередь. Задания из нее поступают на
исполнение только в определенное время, указанное в специальном
конфигурационном файле dedicated_time. Если наступило это время, то
задания, не находящиеся в "ded"-очереди, не рассматриваются. (См. файл
PBS_HOME/sched_priv/dedicated_time)
- Наиболее удобным временем (Prime time) считается время с 4:00 утра до
5:30 вечера. Свободные и праздничные дни считаются неудобными (non-prime).
Сюда включаются стандартные федеральные праздники 1988 года (См. файл
PBS_HOME/sched_priv/holidays)
- Пример файла dedicated_time и файла групповых ресурсов (resource group
file)
также имеются.
- Следующие системные ресурсы также проверяются на достаточность:
mem (затребованная память) и ncpus (количество запрошенных процессоров).
1. В соответствии с Обзором построения, выполните конфигурацию со следующими
параметрами: --set-sched=c и --set-schedcode=fifo,
рекомендуемыми по умолчанию.
2. Вы можете просмотреть файл src/scheduler.cc/samples/fifo/config.h
Большинство параметров по умолчанию вам подойдут.
3. Постройте и установите PBS
4. Войдите в каталог PBS_HOME/sched_priv и отредактируйте конфиг-файл
планировочной политики sched_config, или воспользуйтесь значениями по
умолчанию. Этот файл определяет планировочную стратегию (какие задания и
когда исполнять) Его имя по умолчанию sched_config можно поменять на
config.h. Формат файла sched_config таков:
имя: значение [prime | non_prime | all]
Имя и значение не должны содержать белых пробелов, значением может быть:
true | false | число | цепочка.
Каждая строка, начинающаяся с '#', есть комментарий.
Пробел в позиции третьего слова эквивалентен "all", что означает и prime
и non-prime одновременно.
Соответствующие значения, вставляемые по умолчанию, показаны в
скобках {}
round_robin (ходим кругом друг за другом)
boolean: Если true - выполнять задания по одному из каждой очереди
циклическим образом; если false - выполнять столько заданий, сколько
возможно, из одной очереди, вплоть до пределов queue/server, и только
потом переходить к обработке заданий из следующей очереди.
Следующие атрибуты Сервера и очереди, если установлены, будут
определять, может ли задание исполняться:
resources_max, max_running, max_user_run, и
max_group_run. См. man pages pbs_server_attributes и
pbs_queue_attributes.
{false all}
by_queue
boolean: Если true - будут выполняться задания из их очередей;
если false - все множество заданий в Сервере рассматривается как
одна большая очередь.
{true all}
strict_fifo
boolean: Если true - задания будут выполняться строго в порядке
FIFO. Это значит, что если задание не может выполняться по какой-то
причине, никакие другие задания не будут выполняться из этой
очереди/сервера в этом цикле планирования. Если strict_fifo не
установлен, большие задания могут страдать, то есть не передаваться
на исполнение, потому что непрекращающийся поток малых заданий
занимает доступные ресурсы. См. также об атрибуте сервера
resources_max в разделе 3.5.1, и параметр fifo
help_starving_jobs См. ниже
{false all}
fair_share
boolean: Включает алгорифм fair share. Он также включает
определение употребительности, и будут отбираться задания,
использующие функцию их употребительности и приоритета (shares).
{false all}
load_balancing
boolean: Если это установлено, Планировщик будет распределять
задания на указанных в полученном от Сервера (pbs-server) списке
разделяемых во времени хостов (:ts). Сервер читает этот список в
файле узлов, см. раздел 3.2.
{false all}
help_starving_jobs
boolean: Этот бит побуждает Планировщика включить его рудиментарную
поддержку страдающих заданий. Если задание ожидало в течение времени,
указанного в starve_max, оно считается страдающим. А если какое-то
задание страдает, ни одно другое задание не запускается до запуска
страдающего. Starve_max должно быть тоже установлено.
sort_by
цепочка: сортирует задания. sort_by может быть установлен на
единственный тип сортировки, или на multi_sort. При установке на
multi_sort используются кратные ключевые поля . Каждое ключевое
поле служит ключом для мультисортировки. Порядок ключевых полей
показывает, какой тип сортировки используется первым.
Sorts: no_sort, shortest_job_first,
longest_job_first, smallest_memory_first,
largest_memory_first, high_priority_first,
low_priority_first, multi_sort, fair_share,
large_walltime_first, short_walltime_first
{shortest_job_first}
no_sort
не сортировать задания
shortest_job_first
в возрастающем порядке по атрибуту cput
longest_job_first
в убывающем порядке по атрибуту cput
smallest_memory_first
в возрастающем порядке по атрибуту mem
largest_memory_first
в убывающем порядке по атрибуту mem
high_priority_first
в убывающем порядке по атрибуту job priority
low_priority_first
в возрастающем порядке по атрибуту job priority
large_walltime_first
в убывающем порядке по атрибуту job walltime
cmp_job_walltime_asc
в возрастающем порядке по атрибуту job walltime
multi_sort
сортировка по кратным ключам keys.
fair_share
Если fair_share дан как ключ для сортировки, задания сортируются
на основании значений в resource group file. Это используется
только если необходима сортировка по строгим приоритетам
key Тип сортировки, подобный определенному выше для кратной сортировки.
Каждый сортировочный ключ указан в отдельной строке, начинающейся со
слова key.
Например:
sort_by: multi_sort
key: sortest_job_first
key: smallest_memory_first
key: high_priority_first
log_filter
Какие типы событий не регистрировать. Значение должно быть
суммой (в смысле операции OR) классов событий, которые должны быть
отфильтрованы . Числа определены в src/include/log.h.
ЗАМЕЧАНИЕ: числа шестнадцатеричные, а log_filter работает с
с десятичными числами
{256}
Примеры:
Отфильтровать PBSEVENT_DEBUG2, PBSEVENT_DEBUG и PBSEVENT_ADMIN
0x100: 256 0x080: 128 0x004: 4= 388
log_filter 388
Отфильтровать PBSEVENT_JOB,PBSEVENT_DEBUG и PBSEVENT_SCHED
0x008: 8 0x080: 128 0x040: 64= 200
log_filter 200
dedicated_prefix
Очереди с этим префиксом будут рассматриваться как специализированные
очереди. Пример: если специализированный префикс есть "ded" , то
dedicated, ded1, ded5 и т.д. будут специализированными очередями
{ded}
starve_max
Время ожидания задания, по истечении которого оно считается
страдающим. Эта конфигурационная переменная не используется, если
help_starving_jobs не установлена.
Все последующее не действует, если fair share не включено (по умолчанию
оно выключено).
half_life
Половинный срок употребительности fair share
{24:00:00}
unknown_shares
Количество shares для группы "unknown".
{10}
sync_time
Промежуток времени между записями на диск данных об употребительности
fair share.
{1:00:00}
Стратегия, устанавливаемая поставляемыми значениями в sched_config такова:
Задания исполняются на основе приоритета очередей как во время prime так
и в non-prime.
Задания в каждой очереди упорядочиваются по правилу: требующие меньше
памяти --- первые.
Помощь страдающим заданиям по истечении 24 часов.
5. Если предполагается употребление fair share или строгой приоритетности,
то файл ресурсов групп, {PBS_HOME}/sched_priv/resources_group,
должен быть отредактирован. Пример такого файла был показан. При
редактировании файла используйте следующий формат для каждой строки файла:
# comment
username cresgrp resgrp shares
username
цепочка: имя пользователя или группы
cresgrp
число: идентификатор для группы или пользователя, уникальный в
каждом случае, для пользователей хорошо подходит UID
resgrp
цепочка: имя родительской группы ресурсов, в которой состоит
пользователь/группа. Корень всего дерева называется root и
добавляется к дереву Планировщиком.
sharesnumeric: размер частей (приоритет), которую пользователь/группа
имеет в ресурсной группе.
6. Если нужен строгий приоритет, необходимо дерево сглаженной совместимости.
Подойдет и достаточно простое. Корнем будет каждое пользовательское
resgrp. Их приоритетом будет служить количество долей (shares). Затем
установите unknown_shares на единицу. Каждый, кто не входит в дерево,
будет разделять одну долю среди них, чтобы наверняка каждый в дереве имел
приоритет над ними. Наконец, главный sort должен быть установлен на
fair_share. Это будет сортировать по дереву сглаженной совместимости,
которое только что было определено.
7. Создайте файл свободных дней, чтобы обрабатывать prime time и свободные
дни (holidays). Файл holidays должен использовать формат UNICOS 8
holiday. Нужно учитывать и порядок. Каждая строка, которая начинается с
"*", считается комментарием.
YEAR YYYY
Это текущий год.
День может быть weekday | saturday | sunday
prime и nonprime означают моменты начала времени prime или
nonprime. Они могут быть или HHMM без двоеточий (:) или словом
"all" или "none"
day есть день года между 1 и 365, date есть календарная дата.
Ex Jan 1 holiday есть имя праздника Ex New Year's Day.
Это повторяется для каждого свободного дня компании.
8. Для равномерного распределения нагрузки между разделяемыми во времени
узлами нужно выполнить несколько действий. Во-первых, должен быть
установлен файл узлов с именем PBSHOME/server_priv/nodes. (См. раздел
3.2). Все разделяемые во времени узлы должны быть обозначены добавкой with
:ts в конец имени хоста. Это те узлы, которые Планировщик должен
равномерно нагружать. Во-вторых, на каждом узле должен быть свой Mom.
В конфигурационном файле каждого Mom должны быть определены два
статических значения: одно для идеальной загрузки и другое для
максимальной.
Это делается внесением в конфигурационный файл двух строк формата
name value. Имена должны быть ideal_load и max_load, а значения ---
числами с плавающей точкой. Наконец, нужно установить бит load_balancing bit
в конфигурационном файле политики планирования. Load balancing
будет устанавливать job comment на running, показывая, где исполнялось
задание.
Пример конфигурационного файла Mom :(на машине 64 процессора)
ideal_load 50
max_load 64
Заметим, что директивы $ideal_load и $max_load как раз и создают
соответствующие строки ideal_load и max_load в конфигурационном файле.
9. Пространственное разделение происходит автоматически, если имеются и
файл узлов и запросы заданий на узлы. Обязательно установите
resources_default.nodes и resources_default.nodect.
10. Планировщик использует следующие объекты и связанные с ними атрибуты
-------------|----------------------|------------------------------
Source Object | Attribute/Resource | Comparison
--------------|----------------------|-----------------------------
Queue | started | equal true
Queue | queue_type | equal execution
Queue | max_running | ge #jobs running
Queue | max_user_run | ge #jobs running for a user
Queue | max_group_run | ge #jobs running for a group
Job | job state | equal Queued
Server | max_running | ge #jobs running
Server | max_user_run | ge #jobs running for a user
Server | max_group_run | ge #jobs running for a group
Server | resources_available | ge resources requested by job
Server | resources_max | ge resources requested
Node | loadave | less than configured limit
Node | arch | equal type requested
Node | host | equal name requested
Node | ncpus | ge number ncpus requested
Node | physmem | ge amount mem requested
ЗАМЕЧАНИЕ: if resources_available.res установлен, он и будет
использоваться, а если нет, то будет использоваться resources_max.res
Если ни один не установлен, предполагается бесконечный ресурс res
Дальше идут только примеры. Они могут быть или не быть в поставке.
# Установите Булевские значения, которые определяют, как алгорифм планирования
# находит следующее задание, предназначенное на исполнение.
round_robin: False ALL
by_queue: True prime
by_queue: false non-prime
strict_fifo: true ALL
fair_share: True prime
fair_share: false non-prime
# Помощь заданию, которое ожидало запуска слишком долго
help_starving_jobs: true prime
help_starving_jobs: false non-prime
# Установка multi_sort
# Этот пример будет сортировать задания сначала по возрастанию затребованного
# времени процессора, затем
# по увеличению затребованной памяти и наконец по уменьшению приоритета
# заданий
sort_by: multi_sort
key: shortest_job_first
key: smallest_memory_first
key: high_priority_first
# Установить уровень отладки только на показ сообщений верхнего уровня.
# Временно это показывает только исполняемые задания
debug_level: high_mess
# Задание поступает на исполнение, если оно ждало в течение
max_starve: 24:00:00
# Если Планировщик натыкается на пользователей, которых нет в настоящее время
# в resource group tree, они добавляются в группу "unknown".
# Группа "unknown" находится в корнях группы resource. Это говорит,
# какое количество долей она получает
unknown_shares: 10
# Информацию об употребительности должна записываться на диск в случаях
# отказа Планировщика по какой-то причине. Это есть количество времени с
# с того момента, когда информация об употребительности в памяти писалась на
# диск. В примере это делается каждый час.
sync_time: 1:00:00
# Какие события не нужно регистрировать. Номера событий определены в
# src/include/log.h. NOTE: номера событий шестнадцатеричные, а
# фильтр регистрации работает в десятичной системе. В примере не
# регистрируются события DEBUG2 , наиболее многочисленные.
log_filter: 256
* текущий год
YEAR 1998
*
* Начало и конец prime time
*
* Prime Non-Prime
* Day Start Start
weekday 0400 1130
saturday none all
sunday none all
*
* The holidays
*
* Day of Calendar Company
* Year Date Holiday
*
1 Jan 1 New Year's Day
20 Jan 20 Martin Luther King Day
48 Feb 17 President's Day
146 May 26 Memorial Day
185 Jul 4 Independence Day
244 Sep 1 Labor Day
286 Oct 13 Columbus Day
315 Nov 11 Veteran's Day
331 Nov 27 Thanksgiving
359 Dec 25 Christmas Day
#
# Группы "root" и "unknown" добавляются Планировщиком
# Все родители добавляются перед детьми. Поэтому сначала добавляются все
# группы. Номера cresgrp, которые имею пользователи, служат их
# идентификаторами UID
#
# name resgrp child resgrp shares
grp1 50 root 10
grp2 51 root 20
grp3 52 root 10
grp4 53 grp1 20
grp5 54 grp1 10
grp6 55 grp2 20
usr1 60 root 5
usr2 61 grp1 10
usr3 62 grp2 10
usr4 63 grp6 10
usr5 64 grp6 10
usr6 65 grp6 20
usr7 66 grp3 10
usr8 67 grp4 10
usr9 68 grp4 10
usr10 69 grp5 10
Пример
# Это есть ресурсный групповой файл строгого приоритета. Это люди, кто должен
# получить приоритет над всеми другими. Количество долей есть приоритет
# пользователя.
sally 1000 root 4
larry 1001 root 6
manager 1010 root 100
vp 1016 root 500
ceo 2000 root 10000
Пример
# Format:
# FROM TO
# MM/DD/YYYY HH:MM MM/DD/YYYY HH:MM
04/10/1998 15:30 04/11/1998 23:50
05/15/1998 05:15 05/15/1998 08:30
06/10/1998 23:25 06/10/1998 23:50
Это высоко оптимизированный планировщик для серий IBM SP суперкомпьютеров.
Этот планировщик впервые использовал алгорифм "динамического обратного
наполнения" для SP. Этот алгорифм спроектирован для реализации политики
употребительности, подобной применяемой на традиционных векторных
суперкомпьютерах NAS. Этот алгорифм предназначен прежде всего для минимизации
времени обращения малых заданий в часы Prime-Time и для поддержки возможно
более продуктивного использования узлов в остальные часы. Планирование этих
противоположных загрузок слагается из интерактивных коротких отладок и длинных
пакетных заданий, представляющих значительные трудности на SP, благодаря их
ограниченным способностям в управлении ресурсами и параллельным ограничениями
в планировании заданий (только пространственное совмещение, без разделения
времени). Применяемый пространственно совмещающий алгорифм планирования
использует сложный метод динамического обратного наполнения для преодоления
ограничений SP. Алгорифм доводит время оборота малых заданий до 10 - 20
минут и поддерживает использование узлов на уровне около 75%. См. статью в
каталоге scheduler.cc/samples/ibm_sp с дискуссией по поводу используемого
алгорифма.
1. В соответствии с Обзором построения, выполните конфигурацию со
следующими параметрами:
--set-sched=cc и --set-sched-code=ibm_sp
2. Просмотрите src/scheduler.cc/samples/ibm_sp/sched_globals.h и
отредактируйте все необходимые переменные, такие как значения
SCHED_DEFAULT_CONFIGURATION.
3. Постройте и установите PBS.
4. Войдите в каталог {PBS_HOME}/sched_priv и отредактируйте файл
конфигурации планировщика "config" (см. 4.5.2.2). Этот файл управляет
стратегией планирования, определяющей, когда и какие задания запускать.
Комментарии в конфиг-файле поясняют назначение параметров. При сомнении
используйте параметр по умолчанию.
Конфигурационный файл Планировщика ibm_sp содержит следующие настраиваемые
параметры, управляющие реализуемой Планировщиком стратегией. Комментарии
начинаются с '#'. Остальные строки рассматриваются как операторы и должны
подчиняться синтаксису:
Это высокоспециализированный планировщик для управления кластером систем
SGI Origin2000, обеспечивающих интегрированную поддержку для обслуживания
массивов (для программ MPI), и NODEMASK (для контактных приложений (pin
applications) с помощью софтвера к динамически создаваемым областям узлов в
пределах системы). Алгорифм планирования включает применение статического
обратного заполнения и динамически подсчитываемых NODEMASKs для отдельных
заданий. (См. файл README в каталоге scheduler.cc/samples/sgi_origin
для ознакомления с деталями алгорифма.)
1. Как об этом говорилось в Обзоре построения, выполните конфигурацию со
следующими параметрами:
--set-sched=cc --set-sched-code=sgi_origin
Если хотите, чтобы планировщик использовал устройство NODEMASK, то добавьте
параметр --enable-nodemask.
2. Просмотрите src/scheduler.cc/samples/sgi_origin/toolkit.h и
отредактируйте необходимые переменные, такие как значение
SCHED_DEFAULT_CONFIGURATION.
3. Постройте и установите PBS.
4. Войдите в каталог {PBS_HOME}/sched_priv и отредактируйте конфигурационный
файл планировщика "config" (см. 4.4.3.2). Этот файл управляет планировочной
стратегией, используемой для определения того, когда и какое задание запускать.
Комментарии в файле объясняют смысл каждого параметра. При сомнении обычно
избирают параметр по умолчанию.
Файл {PBS_HOME}/sched_priv/config содержит называемые ниже настроечные
параметры, управляющие стратегией планировщика. Комментарии допускаются в
любых местах файла. они начинаются со знака '#'. Все строки, не являющиеся
комментариями, служат операторами с синтаксисом:
Это высокоспециализированный планировщик для системы Cray T3E MPP.
Вспомогательные коды для этого планировщика (анализатор конфигурационного
файла, чтение внешних файлов, спецификации ограничений и т.д.)
основываются на ранее рассмотренном планировщике SGI Origin (см. раздел
4.4.3) .
Алгорифм распределения есть реализация основанный на приоритетах системы,
в которой задания наследуют начальный приоритет очередей, в которые они сначала
поступают, а затем
приоритет меняется на основании разных факторов. Они включают такие
переменные, как: длина времени, проведенного в очереди, длина запрошенного
времени, время дня, количество запрошенных узлов и/или количество запрошенной
памяти, и т.д. (См. файл README в каталоге scheduler.cc/samples/cray_t3e
с деталями алгорифма и конфигурационными параметрами.)
1. Следуя Обзору построения, выполните конфигурацию со следующими параметрами:
--set-sched=cc --set-sched-code=cray_t3e
Если хотите побудить Планировщика использовать устройство PEMASK, то
добавьте параметр --enable-pemask.
2. Просмотрите src/scheduler.cc/samples/sgi_origin/toolkit.h, редактируя
необходимые переменные, такие как значения SCHED_DEFAULT_CONFIGURATION.
3. Постройте и установите PBS.
4. Войдите в каталог {PBS_HOME}/sched_priv и отредактируйте конфигурационный
файл планировщика "config" (см. 4.4.5.2). Это файл направляет политику
планирования, используемую для определения того, когда и какое задание
запускать. Комментарии в этом файле поясняют смысл параметров. В
сомнительных случаях обычно приемлемы параметры по умолчанию.
Файл {PBS_HOME}/sched_priv/config содержит настраиваемые параметры, которые
управляют политикой, реализуемой Планировщиком. Комментарии в файле
допускаются повсеместно. Они начинаются с символа '#'. Всякая строка-не
комментарий рассматривается как оператор с синтаксисом:
Этот планировщик поддерживает "мультизадачность" (т.е. разделение во времени
ресурсов памяти и процессоров). Написанный первоначально для
SGI PowerChallenge и позднее перенесенный на Origin 2000, этот планировщик
должен работать на большинстве мультипроцессорных систем с разделяемой
памятью (системах SMP).
1. Согласно Обзору построения, выполните конфигурацию со следующими
параметрами:
--set-sched=cc --set-sched-code=multitask
2. Пересмотрите src/scheduler.cc/samples/multitask/toolkit.h и отредактируйте
все необходимые переменные, такие как SCHED_DEFAULT_CONFIGURATION.
3. Постройте и установите PBS.
4. Войдите в каталог PBS_HOME/sched_priv и отредактируйте конфигурационный
файл планировщика "config". Это файл управляет политикой Планировщика в
определении того, какие задания и когда запускать.
Комментарии в этом файле объясняют роль каждого параметра.
При сомнениях обычно выбирают параметр по умолчанию.
Необходимо принять решение, когда начинать установку файлов для задания. Файлы
должны быть доступны перед началом выполнения задания. Время, которое
потребуется для копирования файлов, неизвестно PBS, оно зависит от размера
файлов и скорости сети. Если установку файлов не начать, пока задание еще не
не выбрано для исполнения, а другие необходимые ресурсы доступны, то либо эти
ресурсы будут простаивать до окончания установки, либо стартует другое задание,
которое перехватит эти ресурсы и не даст стартовать первому. Если же файлы
устанавливать заблаговременно, до того как задание готово к исполнению по
другим параметрам, файлы могут занять ценное пространство на диске,
необходимое для исполняемых заданий.
PBS предоставляет два пути, по которым файлы в состоянии установки могут
быть инициированы для задания. Если требование на исполнение выдано для
задания с требованием на установку файлов, то начинается операция установки и
после ее завершения задание запускается. Или специальный запрос на установку
может быть получен для задания, см. pbs_stagein(3B), и в этом случае файлы
устанавливаются, но задание не запускается. И когда оно потом запускается,
исполнение начинается немедленно, потому что файлы уже там.
В любом случае, если нужные заданию файлы не установлены по какой-то причине,
задание переходит в состояние ожидания с условием выполняться после момента
PBS_STAGEFAIL_WAIT, (спустя 30 минут). Владельцу задания посылается извещение,
чтобы он/она разрешили проблему. Причина перевода задания в состояние
ожидания --в том, чтобы предотвратить Планировщик от постоянных попыток
запустить задание, которые будут наверняка неудачными.
Рис. 5.0 в приложении B в ERS показывает изменение подсостояний для задания,
связанного с установкой файлов. Планировщик может заметить подсостояние
задания и решить выполнить предустановку через вызов pbs_stagein().
Подсостояние покажет также выполнение или неудачу операции. Разработчик
Планировщика должен тщательно выбрать подход к установке, учитывая такие
факторы как вероятные источники файлов, скорость сети и возможности дисков.