Руководство пользователя системы МВС-1000/mvse.

• многопроцессорный вычислитель;
• управляющая ЭВМ;
• сервер доступа;
• файловый сервер (система хранения данных).

Вычислитель состоит из соединенных одной или несколькими высокоскоростными сетями вычислительных модулей (ВМ), каждый из которых уникально именован в системе.

Для примера будем считать, что условное имя управляющей ЭВМ – head, условное имя сервера доступа – login, а условные имена ВМ – node1, node2, node3 и т.д. ВМ образуют решающее поле вычислителя.

• уникальное сетевое имя ВМ (в примере из рисунка 1 – node1, node2 и node3);
• число процессоров (ядер) на ВМ;
• дополнительные вычислительные ресурсы в соответствии с 1.6.

• свободен (free) – ВМ исправен, но в текущий момент времени не используется ни одним заданием;
• используется (used) – ВМ исправен, и в текущий момент времени выделен для выполнения некоторого задания;
• блокирован (locked) – ВМ выведен из решающего поля либо автоматически по причине обнаруженной неисправности, либо по команде оператора.

• прием входного потока заданий;
• выделение для задания требуемых ресурсов;
• при невозможности немедленного выделения требуемых ресурсов – ведение очереди заданий;
• освобождение занятых заданием ресурсов в любой момент времени.

• сервер очередей;
• служебные серверные процессы: сервер запросов, сервер запуска, менеджер задания;
• клиентские процессы (команды программиста);
• служебные процедуры выделения и освобождения вычислительных ресурсов;
• команды и утилиты программиста, оператора и системного программиста.

Сервер запросов проводит авторизацию пользователя в СУППЗ, после чего принимает от клиентской утилиты и выполняет команду программиста, возвращая в клиентскую часть результат выполнения.

• output – файл, куда перенаправляется стандартный поток вывода процессов задания;
• errors – файл, куда перенаправляется стандартный поток ошибок процессов задания;
• input – файл стандартного ввода процессов задания, создается как символическая ссылка на файл стандарнтого ввода, только если этот файл был задан при запуске задания в соотсвествии с 3.1.1.6 или с 4.1.1.5;
• .hosts – файл со списком ВМ, выделенных для задания;
• manager.log – файл журнала процесса-менеджера задания;
• runmvs.bat – командный файл сценария выполнения задания в соответствии с 4.1.1.6.

Имя каталога ввода-вывода задания совпадает с полным именем задания, создается он, как правило, в том каталоге, из которого программист запускает задание, изменить его расположение можно в соответствии с 3.1.1.5 или с 4.1.2.3.

При повторном запуске задания с одним и тем же полным именем все указанные в 2.1.9 файлы автоматически пересоздаются и перезаписываются без уведомления пользователя.

Например, если шкала имеет следующий вид

(120,300,600,1200,0)

Планировщик может запускать задания, стоящие в очереди позже, если это не повлияет на время старта задания, стоящего в очереди ранее (применяется т.н. алгоритм «обратного заполнения»). Такое возможно, например, в случае, если для задания А, стоящего в очереди ранее, недостаточно ресурсов, и при этом задание Б, стоящее в очереди позже, успеет завершиться до момента, когда освободится достаточное количество ресурсов для запуска задания А.

mpirun –np <nproc> [mpirun_args] <MPI_prog> [MPI_prog_args]

Команда mpirun автоматически формирует паспорт задания и направляет его в очередь СУППЗ. Завершение команды mpirun не означает завершение или запуск задания (за исключением случая, рассмотренного в 3.1.1.4), а лишь завершение постановки задания в очередь. При успешном завершении команда mpirun возвращает 0, иначе – отличное от 0 значение с выдачей диагностического сообщения в сандартный поток ошибок. Исключение составляет случай, рассмотренный в 3.1.1.17.

Все параметры команды mpirun являются ключевыми, т.е. предваряются ключевым словом со знаком -.

Параметр -termsignal задает сигнал, который будет разослан всем процессам задания в качестве предупреждения о предстоящем завершении в соответствии с 2.2.6.2. Формат задания сигнала должен соответствовать команде ОС Linux kill. Если параметр –termsignal не будет задан, значение сигнала будет взято из пользовательского конфигурационного файла в соответсвии с 4.1.2.3.

Пусть конфигурация дополнительных ресурсов соответствует примеру из 3.3.6. Допустим, для программы с именем cpi, рассчитанной на выполнение на 10 процессорах, требуется, чтобы на всех выделенных ВМ было не менее 16 Гб оперативной памяти. Команда mpirun в этом случае должна выглядеть следующим образом

mpirun –np 10 –resource "mem=16" cpi

В результате для задания будут выделены модули node2 и node3, т.к. на каждом имеется не менее 16 Гб памяти. Если же задать значение ресурса 32 Гб, то будет выдана ошибка, т.к. задаче требуется минимум 2 модуля (10 процессоров), но в системе есть только один (node2), обладающий необходимым ресурсом.

Параметр –resource может при необходимости повторяться в команде mpirun для возможности указания нескольких вычислительных ресурсов, например

mpirun –np 8 –resource "mem=16" –resource "gpu=yes" cpi

В этом случае для задачи будет выделен модуль node3 (16 Гб оперативной памяти и наличие графического ускорителя).

Допустим, число процессоров (ядер) на каждом ВМ равно 8. Тогда по команде

mpirun –np 16 myprog

mpirun –np 16 –ppn 4 myprog

mrunf [-fo] <паспорт>

Если задан параметр –fo, то при успешном запуске (постановке в очередь) задания команда mrunf выведет полное имя задания в соответствии с 2.1.8 в стандартный поток вывода.

mqdel <имя_задания>

Команда mqdel применима лишь к тем заданиям, которые ожидают выполнения в очереди.

Удаление всех поставленных в очередь заданий осуществляется командой

mqdel '*'

mkill [имя_задания]

mterm [имя_задания]

Команды mkill и mterm применимы только к выполняющимся заданиям.

Завершение всех выполняющихся заданий осуществляется одной из двух команд

mkill '*'

mterm '*'

Если задание фоновое, по команде mkill оно завершит очередной квант и будет заново поставлено в очередь. Команда mterm завершает задания без возврата в очередь, т.е. производит полное завершение задания.

При отсутствии параметра в командах mkill и mterm пользователю будет выдан список всех выполняющихся заданий и предложено ввести номер (по списку) задания, которое нужно завершить. Перед завершением задания будет задан вопрос о полном завершении.

Следует отметить, что команды mkill и mterm лишь сообщают СУППЗ о необходимости завершить задания, но реально не дожидаются его завершения. После успешного выполнения команд mkill и mterm задание может находиться в системе довольно продолжительное время, которое нужно системе для корректного освобождения вычислительных ресурсов. Для ожидания завершения задания следует использовать команду mcancel в соответствии с 3.1.5.

mcancel [имя_задания]

Команда mcancel не закончит своего выполнения до тех пор, пока задание не покинет систему, т.е. команда mcancel, в отличие от команд mkill и mterm, рассмотренных в 3.1.4, ожидает завершения задания.

mwait [имя_задания]

Команда mwait будет ожидать («подвиснет») до тех пор, пока стоящее в очереди или запущенное задание не закончит выполнение и не покинет систему. Для отладочных и пакетных заданий этот момент наступает во время завершения. Для фонового задания – во время завершения последнего кванта либо снятия с выполнения по команде mterm в соответствии с 3.1.4. Кроме использования команды mwait, дождаться завершения задания можно, задав ключ -wait в команде mpirun в соответствии с 3.1.1.4.

Стандартный вывод (печать на экран) задачи можно просмотреть с помощью команды

mout [имя_задачи.номер_задачи [что_выдавать]]

При отсутствии параметров будет предложен выбор из списка запущен-ных задач. При отсутствии параметра что_выдавать будет предложен вопрос. В качестве ответа можно задать либо out, что означает выдачу стандартного вывода, либо err, что означает просмотр стандартного вывода сообщений об ошибках, либо log. В случае задания log на экран будет выведен стандартный вывод специального системного процесса-менеджера задачи.

Если Вы задали параметры команде mout, то она выдаст вам запрошенную информацию, даже если задача уже завершилась на момент вызова команды.

Прервать выдачу команды mout можно нажатием клавиш <Ctrl+C>. Снятие вывода НЕ означает снятие задачи – задача продолжит счет.

При запуске задачи система создаст в указанном в паспорте каталоге стандартного ввода/вывода подкаталог, имя которого будет совпадать с именем запущенной задачи (включая номер через точку). В этом подкаталоге и будут непосредственно размещены файлы стандартного ввода/вывода задачи. Файл стандартного вывода имеет имя output, стандартного вывода сообщений об ошибках – errors, стандартного ввода – input. Файл стандартного вывода процесса-менеджера имеет имя manager.log. Система сама не уничтожает эти файлы и подкаталог, зато перезаписывает их, если задача будет запущена повторно с этим же номером. После завершения задачи данные файлы полностью доступны пользователю.

mqinfo [-s system]

Current time:  Mon Mar 22 13:10:07 2014
Queue state at Mon Mar 22 13:06:09 2014
     Current schedule: 2      
     Accumulation period: 168 hours

--- 22.03.14 07:30: R=1 total–30 debug–0/0, packet–300, priority scale-(10000)
stok3.2:lara 0.1  0*  14  150/150      16    >:03.22.14 18:03
intro.1:kira 0.2  0*  7   60/60+10         6    >:03.22.14 18:05
-- queue --
color.2:vera 0.3  0*  14  100/100      b~~~    <:03.22.02 14:33
--- 23.03.14 07:30: R=1 total–30 debug–0/0, packet–300, priority scale-(10000)
--- 24.03.14 07:30: R=1 total–30 debug–0/0, packet–300, priority scale-(10000)

Free: 0 proc   Available: 18  Locked: 12


   lara: Inf:3 R=1 run=1 wait=0/5 all=0/7   *1.00 Sr/Sf=10/26   
   kira: Inf:3 R=1 run=1 wait=0/5 all=0/7   *1.00 Sr/Sf=10/26   
   vera: Inf:3 R=1 run=0 wait=0/5 all=1/7   *1.00 Sr/Sf=10/26
   u1310: Block:RQ Inf:2 R=1 run=0 wait=0/5 all=0/7   *1.00 Sr/Sf=2/2
::THE_OTHERS:: Inf:3 R=1 run=0 wait=0/5 all=0/10   *1.00 Sr/Sf=0/0
   runmvs: Inf:3 R=2 run=0 wait=0/5 all=0/50   *1.00 Sr/Sf=0/0
   natasol: Inf:3 R=5 run=0 wait=0/5 all=0/50   *0.01 Sr/Sf=0/0

• дату и время включения режима в соответствии с 2.2.4.1;
• после R= – шкалу доступа к режиму в соответствии с 2.2.4.2;
• после total – общее число планируемых процессоров в соответствии с 2.2.4.3;
• после debug – количество процессоров, отведенное под отладочные задания/максимальное время (в минутах) для отладочных заданий в соответствии с 2.2.4.4;
• после packet – максимальное время (в минутах) для пакетных заданий в соответствии с 2.2.4.5;
• после priority scale – шкала приоритетов в соответствии с 2.2.4.6.

• имя задания в соответствии с 2.1.8;
• имя пользователя – владельца задания;
• составной индикатор порядка выделения ресурсов в соответствии с 2.2.5;
• количество оставшихся повторов счета, всегда 0;
• количество процессоров (ядер), занимаемых заданием;
• остаток времени обработки в минутах;
• квант счета в минутах, для отладочных и пакетных заданий всегда совпадает с временем обработки;
• после + – дополнительное время в соответствии с 2.2.6;
• количество минут до предполагаемого завершения задания;
• предполагаемое время завершения (после >:).

В примере на рисунке 1 обрабатываются два задания: stok3.2 пользователя lara и intro.1. пользователя kira. Задание stok3.2 выполняется на 12 процессорах с максимальным временем 150 минут, а задание intro.1 – на 6 процессорах с максимальным временем 60 минут. Заданию stok3.2 осталось обрабатываться 16 минут, а заданию intro.1 – 6 минут. Для задания intro.1 задано дополнительное время 10 минут.

img1.3 : guest      6.3  0*  15  150/15+1      starting
img1.2 : guest      5.2  0*  15  150/150       finishing

Free: 0 proc   Available: 18  Locked: 12

• имя пользователя;
• информация о запрете (Block:) счета (Q) или запуска (R) заданий (если он установлен системным программистом);
• степень подробности (от 1 до 3) выдачи информации (Inf:) о заданиях других пользователей:
  1. степень подробности 1 – пользователю выдается информация только о его собственных заданиях;
  2. степень подробности 2 – пользователю не выдается информация о заданиях других пользователей и информация о пользователях, которые в учетный период не считали и не имеют заданий в очереди;
  3. степень подробности 3 – пользователю выдается вся информация о всех заданиях всех пользователей и вся информация о всех пользователях;
• шкала доступа к режимам (R=) в соответствии с 2.2.4.2;
• после run – количество выполняющихся заданий;
• после wait – количество ждущих заданий/ограничение на количество ждущих заданий;
• после all – суммарное количество заданий в очереди/ограничение на суммарное количество заданий в очереди;
• цена задания в соответствии с 2.2.4.7;
• после Sr/Sf – суммарная стоимость выполняющихся заданий/суммарная стоимость завершившихся заданий в соответствии с 2.2.4.6.

Queue state at Wed Mar 22 12:40:07 2011
       Current schedule: 2      Hold
Accumulation period: 168 hours

--- 22.03.11 07:30: R=3 total–32 debug–8/5, packet–300, priority scale-(120 300)
--- 22.03.11 19:00: R=2 total–32 debug- 0/0, packet-600, priority scale-(10000)
tnet.7 : ant          1*   10  15/15      H~~~   <:Mon Mar 22 13:31:09 2011
tnet.3 : ant          1*   24  500/500  H~~~   <:Mon Mar 22 20:31:09 2011
tnet.1 : ant          1*   1  15/15      H~~~   <:Mon Mar 20 20:31:09 2011
..............................................................................

mps [имя_задания]

Task "mpi.1" started 05.11.14 01:11:42
It's settings are:
Task directory: /home/ivanov/mpi/mpi.1
Pid of manager: 17415
CPU count: 14

NODE CPU
------ ---
1. node19                 7
2. node29                 7

Task "mpi.1" started 05.11.14 01:11:42

После этого выводится таблица со столбцами NODE и CPU, в которых приводятся имена выделенных для задания ВМ и число используемых процессоров (ядер) на каждом ВМ соответственно. В нашем примере для задания mpitask.1 было выделено 2 ВМ с именами node19 и node29 по 7 процессоров (ядер) на каждом.

Task "mpi.1" started 05.11.14 01:11:42, done 05.11.14 02:10:02

mlt

mqtest [-rcode] <имя_задания>

Команда mqtest выводит в стандартный поток вывода информацию о текущем статусе задания с именем имя_задания. Статус задания может принимать следующие значения:

• queued – задание ожидает в очереди
• started – задание выполняется;
• done – задание завершено.

При задании параметра -rcode команда mqtest будет возвращать специальные коды возврата:

• 1 – задание ожидает в очереди;
• 0 – задание выполняется;
• 2 – задание завершено;
• от 128 до 255 – произошла ошибка во время выполнения команды mqtest.

mfree

mproc

mninfo

node23: cpu=7 (gpu:"GTX295")
node24: cpu=7 (gpu:"GTX295")
node25: cpu=7 (gpu:"GTX295")

Имя, тип и значение ресурса задаются системным программистом. Если ресурс строковый, то его значение заключается в кавычки. В нашем примере дополнительными ресурсами обладают все модули. Строковый ресурс gpu (графические ускорители) для всех модулей имеет значение "GTX295". Конкретный смысл имен и значений ресурсов определяется системным программистом СУППЗ.

• выделение ВМ решающего поля без запуска задания в соответствии с 3.4.2 необходимо в тех случаях, когда программисту требуется вычислительный ресурс в виде одного или несколько ВМ на определенное время, но при этом нет необходимости запускать конкретное задание или параллельную программу;
• работа с интерактивными заданиями в соответсвии с 3.4.3;
• поиск в СУППЗ задания пользователя по данным паспорта в соответствии с 3.4.4.

getnodes –np <число_ВМ> [-maxtime <время>] <имя_запроса>

• число_ВМ – число запрашиваемых ВМ (не процессоров или ядер);
• время – максимальное время, на которое запрашиваются ВМ;
• имя_запроса – имя, которое будет присвоено запросу на требуемый вычислительный ресурс.

При успешном выполнении запроса в файл стандартного вывода задания (файл output в соответствии с 2.1.9) будет помещена информация о выделенных ВМ. С момента выделения ВМ, т.е. после прохождения запроса через очередь, любой из выделенных ВМ становится доступен программисту с помощью команд ssh или rsh (в зависимости от настроек, заданных системным программистом). Досрочное завершение работы с выделенными ВМ и снятие задания (запроса) с выполнения осуществляется в соответствии с 3.1.4.

mattach [имя_задания]

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

mfind <имя_секции> <имя_параметра> <маска_значения>

• имя_секции – имя секции паспорта задания в соответствии с 4.1.1;
• имя_параметра – имя параметра указанной секции паспорта задания в соответствии с 4.1.1;
• маска_значения – диапазон значений указанного параметра паспорта задания.

mfind General task_name 'g*'

mfind TimeRequest limit 100

Как правило, содержимое секции составляют пары вида

параметр=значение

Если в значении строкового параметра присутсвуют пробелы, то такое значение должно быть заключено в двойные кавычки. Комментарии в паспорте допустимы, должны начинаться на #, и будут игнорироваться при разборе паспорта. Пример оформления секции паспорта задания:

# Это комментарий
# Следующая строка – начало секции с именем Section1
[Section1]
# Следующая строка – параметр par1 со значением 100
par1 = 100
# Следующая строка – параметр par2 со значением Hello, World!
# Поскольку значение содержит пробел, оно заключается в кавычки
par1 = "Hello, World!"

• обязательный параметр task_name задает имя задания, которое служит основой для формирования полного имени задания в соответствии с 2.1.8;
• обязательный параметр host_directory определяет имя домашнего каталога задания, именно в этом каталоге при постановке в очередь в соответствии с 2.1.9 будет создан каталог ввода-вывода задания;
• обязательный параметр cpu_count определяет требуемое число процессоров (ядер) для выполнения задания;
• необязательный параметр system определяет имя логической системы в соответствии с 2.1.7, если параметр system не будет указан, задание будет направлено в логическую систему по умолчанию.

Пример оформления секции [General]:

[General]
# имя логической системы
system = mpi
# имя задания – testmod
task_name = testmod
# имя каталога задания 
host_directory = /home/user/testmod/work
# число процессоров для выполнения задачи
cpu_count = 32

• обязательный параметр limit определяет максимальное время выполнения задания (в минутах), после истечения этого времени задание будет принудительно завершено; сообщение о принудительном завершении задания будет выведено в журнал процесса-менеджера задания в соответствии с 4.2.6; указанное в параметре limit время будет участвовать в расчете приоритета задания в соответствии с 2.2.4.6 – 2.2.4.8;
• обязательный параметр quant определяет размер кванта (в минутах) для фоновых заданий в соответствии с 2.2.2 для пакетных и отладочных задач значение параметра quant должно быть 0 или равно значению параметра limit;
• необязательный параметр term_time задает дополнительное время (в минутах) для завершения задания в соответствии с 2.2.6;
• необязательный параметр term_signal задает сигнал, который будет разослан всем процессам задания в качестве предупреждения о предстоящем завершении в соответствии с 2.2.6.2. Формат задания сигнала должен соответствовать команде ОС Linux kill.

Пример оформления секции [TimeRequest]:

[TimeRequest]
# максимальное время выполнения задания
limit = 200
# квант для фонового задания
quant = 20
# дополнительное время
term_time = 5
# сигнал о завершении
term_signal = USR1

• необязательный параметр stdout определяет имя файла, в который будет перенаправлен стандартный поток вывода процессов задания, если параметр не будет указан, перенаправление будет произведено в соответствии с 2.1.9;
• необязательный параметр stderr определяет имя файла, в который будет перенаправлен стандартный поток ошибок процессов задания, если параметр не будет указан, перенаправление будет произведено в соответствии с 2.1.9;
• необязательный параметр stdin определяет имя файла, на который будет перенаправлен поток стандартного ввода процессов задания. На указанный файл в каталоге ввода-вывода задания автоматически будет создана символическая ссылка с именем input. Если параметр не будет указан, стандартный ввод для процессов задания будет недоступен и не должен использоваться в параллельной программе;
• необязательный параметр interactive может принимать значение yes или no. Указание значения yes делает задание интерактивным в соответствии с 3.4.3 и отменяет значения остальных параметров секции [Redirections].

Пример оформления секции [Redirections]:

[Redirections]
# имя файла стандартного потока вывода задания
stdout = /home/user/test.out
# имя файла стандартного потока ошибок задания
stderr = /home/user/test.err
# имя файла стандартного потока ввода задания
stdin = /home/user/test.in
# задание не интерактивное
interactive = no

При вызове командного файла сценария выполнения задания СУППЗ передаст в него следующие параметры:

• первый параметр – число процессоров (ядер), выделенных для задания;
• второй параметр – имя текстового файла со списком выделенных для задания ВМ; каждая строка файла описывает один выделенный ВМ и имеет следующий формат: node_name:cpu_count, где
  • node_name – имя выделенного ВМ;
  • cpu_count – число процессоров (ядер) на ВМ.
• третий параметр – имя файла, в который программист при желании может записать в текстовом виде код завершения задания;
• четвёртый параметр – имя файла-паспорта задания, из которого программист может считать настройки, заданные как системой, так и самим программистом.

Используя переданные СУППЗ параметры, программист может предусмотреть произвольный порядок развертывания и выполнения процессов задания на выделенных ВМ.

• необязательный параметр tmp_directory определяет имя каталога, в котором команды СУППЗ будут создавать временные файлы. Если параметр не задан, или его значение неправильное (например, нет такого каталога, или нет доступа к обозначенному каталогу), то временные файлы будут создаваться в каталоге /tmp. Параметр применяется для обеспечения конфиденциальности работы пользователя с СУППЗ;
• обязательный параметр host определяет имя управляющей ЭВМ, с которой будет соединяться клиентская утилита runmvs для передачи команд СУППЗ серверу запросов; параметр host не принимается к исполнению, если указан параметр –host в команде mpirun в соответствии с 3.1.1.15.

Пример оформления секции [General]:

[General]
# имя каталога для временных файлов
tmp_directory = ~/my_home_tmp
# имя управляющей ЭВМ
host = su

• необязательный параметр quantum определяет значение по умолчанию параметра –quantum в соответствии с 3.1.1.2; если значение параметра quantum равно 0, то задания по умолчанию не будут фоновыми;
• необязательный параметр maxtime определяет значение по умолчанию параметра –maxtime в соответствии с 3.1.1.1;
• обязательный параметр stdiodir определяет значение по умолчанию параметра –stdiodir в соответствии с 3.1.1.5; перед использованием этот параметр будет обработан командным интерпретатором; категорически рекомендуется указывать значение 'pwd', чтобы каталог ввода-вывода задания создавался в каталоге, в котором запускается команда mpirun;
• необязательный параметр restart принимает значения 0 или 1; если указано значение 1, то по умолчанию будет действовать параметр –restart в соответствии с 3.1.1.3, т.е. задание после выполнения по умолчанию будет вновь поставлено в очередь;
• необязательный параметр term_time определяет значение по умолчанию параметра –termtime в соответствии с 3.1.1.10, указание значения 0 означает отсутствие дополнительного времени для завершения заданий;
• необязательный параметр term_signal определяет значение по умолчанию параметра –termsignal в соответствии с 3.1.1.11, указание значения 0 означает отсутствие сигнала для извещения процессов задания о предстоящем завершении.

Пример оформления секции [Mpirun]:

[Mpirun]
# квант времени для фонового задания
# задан ноль – это означает, что задание не является фоновым
quantum = 0
# время по умолчанию выполнения задания (задается в минутах)
maxtime = 300
# имя каталога задания
# если указано 'pwd' – то создавать каталог
# ввода-вывода задания в текущем каталоге
stdiodir = 'pwd'
# необходимость рестарта задания по его окончании
# 0 – рестарт не производить      
restart = 0
# дополнительное время (в минутах) на завершение задания 
# 0 – нет дополнительного времени
term_time = 0
# сигнал, посылаемый процессам задания для уведомления 
# о предстоящем завершении
# 0 – нет сигнала
term_signal = 0

# Это комментарий
node1:2 # Комментарий м.б.в строке с информацией
node2 # Если не указано число процессов на ВМ,
# запускается один процесс
node3:004 # Могут присутствовать ведущие нули
node6:2 # Порядок следования ВМ
node5:2 # не имеет значения

module4:2 # Ошибка!!! Неправильное имя ВМ
node5: # Ошибка!!! После двоеточия должно быть указано число процессов

node1:3
node2:2

При запуске программы cpi c помощью команды

mpirun –np 5 –machinefile example cpi

node1:3
node2:2

mpirun –np 6 –machinefile example cpi

node1:3
node2
node3:10

mpirun –np 6 –machinefile example cpi

node1:3
node2:4
node3:4

mpirun –np 6 –machinefile example cpi

node1:2
node2
node1:1

mpirun –np 5 –machinefile example cpi

node1:2
node3
node4:2

mpirun –np 5 –machinefile example cpi

node1:2
node3:3
node2:2

mpirun –np 5 –machinefile example cpi

имя_модуля = [имя_ресурсной_секции]

Если имя ресурсной секции не задано, это будет означать, что для данного модуля не заданы ресурсные требования. Ресурсные секции могут иметь произвольные имена, задаваемые программистом. Каждая ресурсная секция описывает дополнительные ресурсы, требуемые для того или иного ВМ. Заметим, что если для нескольких ВМ ресурсные требования совпадают, то для этих модулей в секции [Resources] можно указать одну и ту же ресурсную секцию. Рассмотрим пример файла-спецификации с комментариями.

[Resources]
# требования для модулей node1 и node2 будут заданы в секции R1
node1 = [R1]
node2 = [R1]
# требования для модуля node3 будут заданы в секции R2
node3 = [R2]
# Ресурсная секция R1 требования к ресурсам для node1 и node2
[R1]
# Числовой ресурс
gpu = 3
# Если значение строкового ресурса содержит  
# пробелы, то оно заключается в кавычки
OS = "Linux SUSE"
# Ресурсная секция R2 требования к ресурсам для node3
[R2]
# Числовой ресурс
gpu = 3
# Строковый ресурс 
pciex = yes 

[Resources]
# Для первого модуля задаем ресурсные требования через секцию R1
node1 = [R1]
# Для node2 и node3 требования не заданы
node2
node3
# Ресурсная секция R1 требования к ресурсам для node1 
[R1]
# Числовой ресурс
gpu = 2

mpirun –np 24 –resourcefile myres myprog

[Resources]
# Для node1 и node2 требования не заданы
node1
node2
# Для последнего модуля задаем ресурсные требования через секцию R1
node3 = [R1]
# Ресурсная секция R1 требования к ресурсам для node3 
[R1]
# Числовой ресурс
gpu = 1

mpirun –np 24 –resourcefile myres myprog

[Resources]
# Для первого модуля задаем ресурсные требования через секцию R1
node1 = [R1]
# Для node2 требования не заданы
node2
# Для последнего модуля задаем ресурсные требования через секцию R1
node3 = [R1]
# Ресурсная секция R1 требования к ресурсам для node1 и node3 

[R1]
# Числовой ресурс
gpu = 3

mpirun –np 24 –resourcefile myres myprog

[Resources]
node1 = [R1]
node2
node1 = [R1]
[R1]
gpu = 2

runmvsd: form_qimage: multiple entries of node node1
in section [Resources] of task image

[Resources]
node1 = [R3]
node2
[R1]
gpu = 3

runmvsd: form_qimage: missing section [R3]
for node node1 in section [Resources]

• errors – файл, куда перенаправляется стандартный поток ошибок процессов задания;
• .hosts – файл со списком ВМ, выделенных для задания;
• manager.log – файл журнала менеджера задания СУППЗ.

• от коммуникационных и программных библиотек, используемых в параллельной программе из состава задания;
• от ОС ВМ об ошибочных и аварийных ситуациях, возникших при выполнении процессов задания;
• сообщения, предусмотренные самим программистом.

node_name:cpu_count

• node_name – имя выделенного ВМ;
• cpu_count – число процессоров (ядер) на ВМ.

• информация о подготовке задания к выполнению;
• информация о выполнении и завершении процессов задания;
• информация об освобождении ВМ после заверешения задания.

***********
Task started in 1 time of 1 at 10.11.14 09:50:13
Preparing nodes for user ant
******************* node17 **********************
Host node17 has been prepared
******************* node16 **********************
Host node16 has been prepared
Starting task process with pid 29933
Sleeper 29934 started at 10.11.14 09:50:14 for 5 minutes
Pid of sleeper is 29934
Signals set
SIGUSR2 received, killing sleeper
Killing sleeper 29934
manager: sleeper 29934 was completed on a SIGHUP, signal 12 has detected
Killing child tasks of pid 29933
manager: process 29933 done at 10.11.14 09:51:15
Creating done-file /usr/runmvs/users/ant/done/cpi.1
Done-file created successfully
10.11.14 09:51:15: manager: closing nodes
Close nodes started
Executing /usr/runmvs/bin/trycmd 3 /usr/runmvs/bin/cmd 540 /usr/bin/ssh on node
node16
Executing /usr/runmvs/bin/trycmd 3 /usr/runmvs/bin/cmd 540 /usr/bin/ssh on node
node17
Rsh on node node19 Ok
Rsh on node node18 Ok
close_nodes: node node16 has been successfully freed
close_nodes: node node17 has been successfully freed
close_node: close_nodes script done
10.11.14 09:51:21: manager: close_nodes done
Unlocking nodes ...
closing SLA quota...
Exiting...

Рисунок 3 – Пример файла журнала менеджера задания

Task started in 1 time of 1 at 10.11.14 09:50:13

Preparing nodes for user ant

Starting task process with pid 29933

manager: process 29933 done at 10.11.14 09:51:15

Done-file created successfully

Close nodes started

**** WARNING!!! The task has exhausted settled time!!! ****

***********
Task started in 1 time of 1 at 10.11.14 09:50:58
******************* node15 **********************
Host node15 has been prepared
Preparing nodes for user ant
/usr/runmvs/bin/prepare_nodes '/usr/runmvs/users/ant/queue/cpi.2'
Starting task process with pid 30305
Sleeper 30306 started at 10.11.14 09:50:59 for 1 minutes
Pid of sleeper is 30306
Signals set
Sleeper 30306 got up at 10.11.14 09:51:59, testing end of task
10.11.14 09:51:59: sleeper: msgget to qserver ok, sending message
10.11.14 09:51:59: sleeper: printflog done
10.11.14 09:51:59: sleeper: msgget from qserver ok, recieving reply

**** WARNING!!! The task has exhausted settled time!!! ****

manager: sleeper 30306 was comleted with code 4
Killing child tasks of pid 30305
manager: process 30305 done at 10.11.14 09:52:04
Creating done-file /usr/runmvs/users/ant/done/cpi.2
Done-file created successfully
10.11.14 09:52:04: manager: closing nodes
Close nodes started
Executing /usr/runmvs/bin/trycmd 3 /usr/runmvs/bin/cmd 540 /usr/bin/ssh on node
node15
Rsh on node node15 Ok
close_nodes: node node15 has been successfully freed
10.11.14 09:52:09: manager: close_nodes done
Unlocking nodes ...
closing SLA quota...
Exiting...

Рисунок 4
Пример файла журнала менеджера задания для случая,
когда задание было принудительно снято с выполнения
по причине исчерпани заказанного времени

• сообщения об ошибках при обращении к СУППЗ;
• системные сообщения об ошибках процессов обработки задания, которые могут быть выведены в:
  1. файл стандартного потока ошибок задания;
  2. файл журнала менеджера задания СУППЗ.

Таблица 1
Диагностические сообщения при выполнении команд СУППЗ