Параллельное тестирование

Навигация: Главная страница/Система ejudge/Использование/Параллельное тестирование

Система ejudge поддерживает распараллеливание тестирования программ как на многоядерных процессорах, так и по сети. На каждом экземпляре тестировщика единицей тестирования является одна посылка, то есть на тестирование берется исполняемый файл, и пока он не будет проверен до конца (в зависимости от типа турнира либо на всех тестах, либо до первого неуспешного тесте), данный тестировщик не перейдет к тестированию следующего решения.

Очередь тестирования является общей для всех турниров, в очереди посылки упорядочиваются по приоритету тестирования. Чем меньше значение приоритета, тем выше приоритет. Стандартное значение приоритета - 0. Значние приоритета может быть повышено до +15 (минимальный приоритет), либо понижено до -16 (максимальный приоритет). Отталкиваясь от базового значения 0 приоритет тестирования можно изменять для всего турнира, задачи, языка программирования, пользователя и т. п. Кроме того, решения, оправляемые на перепроверку, получают +3 к приоритету.

За тестирование посылок отвечает программа ej-super-run.

Параллельное тестирование на многоядерном процессоре

Для параллельного тестирования на одном процессоре достаточно запустить столько экземпляров программы ej-super-run, сколько требуется. Параллельно работающие экземпляры ej-super-run не конфликтуют между собой.

Для настройки автоматического запуска необходимого количества экземпляров программы ej-super-run при старте ejudge в конфигурационный файл ejudge.xml необходимо добавить следующий фрагмент.

<config>
  ...
  <hosts_options>
    <host name="IP-ADDRESS">
      <option name="parallelism" value="3" />
    </host>
  </hosts_options>
  ...
</config>

Фрагмент, как показано, добавляется внутрь корневого элемента <config>. Вместо IP-ADDRESS необходимо подставить IP-адрес сервера. В значение атрибута value подставляется требуемое количество параллельно запускаемых экземпляров ej-super-run.

ВНИМАНИЕ. На многоядерной машине узким местом скорее всего окажется дисковая подсистема. Если будет указан большой параллелизм компиляции и выполнения может оказаться так, то дисковая подсистема не справится с потоком запросов. В этом случае в списке процессов будет много процессов, находящихся в состоянии 'D' (uninterruptible sleep).

Параллельное тестирование на нескольких компьютерах по сети

При параллельном тестировании по сети всем тестирующим компьютерам должен быть доступен каталог с турнирами ejudge. Путь к этому каталогу задается при конфигурировании ejudge с помощью опции --enable-contests-home-dir. Предположим, что ejudge сконфигурирована со значением данной опции равным /home/judges, то есть конкретные турниры размещаются в каталогах /home/judges/000001 и т. д.

Каталог /home/judges для тестирующих компьютеров должен быть доступен как на чтение, так и на запись. Тестирующие компьютеры используют тестовые данные и проверяющие программы, находящиеся в соответствующих каталогах, только для чтения, но читают и записывают файлы из каталогов обмена данными. По умолчанию каталоги обмена данными создаются открытыми для всех на запись, поэтому система ejudge на тестирующих компьютерах может работать и под другим идентификатором пользователя, чем на сервере.

Тип сетевой файловой системы для каталога /home/judges не имеет значения. Это может быть как NFS, SMB, так и SSHFS, то есть тестирующие компьютеры могут взаимодействовать с сервером по защищенному протоколу через Интернет.

После настройки сетевых каталогов тестирование запускается аналогично локальному тестированию, то есть с помощью ej-super-run.

Пример:

sshfs USER@SERVER:/home/judges /home/judges -o ServerAliveInterval=30,reconnect,allow_other
cd /home/judges
/opt/ejudge/bin/ej-super-run

Здесь предполагается, что система ejudge установлена в каталог /opt/ejudge. Если при конфигурировании ejudge была указана опция --enable-hidden-server-bins, программа ej-super-run размещается по пути /opt/ejudge/libexec/ejudge/bin/ej-super-run.

Оптимизация тестирования по сети

Размещение рабочих каталогов и временных файлов на локальной файловой системе. По умолчанию рабочие каталоги для запуска тестируемых программ размещаются в подкаталоге var турнира или в подкаталоге /home/judges/super-run/var. На тестирующих компьютерах, которые подключают сетевой каталог /home/judges, рабочие каталоги тоже окажутся на сетевом диске. Тестирование будет работать корректно, но медленно, из-за лишних операций с сетевой файловой системой.

Для того, чтобы рабочие каталоги и временные файлы располагались в другом месте (на локальной файловой системе), при конфигурировании ejudge необходимо указать опцию --enable-local-dir, указав путь к локальному каталогу. Например, --enable-local-dir=/var/lib/ejudge.

Кеширование тестовых данных и проверяющих программ. Файлы с тестами и проверяющими программами можно кешировать на локальной файловой системе, чтобы избежать пересылок файлов по сети каждый раз, когда они требуются при тестировании. Для этого используется опция -m программы ej-super-run. Например,

ej-super-run -m /tmp/super-run

в этом случае для локального кеширования файлов будет использоваться каталог /tmp/super-run.

Поддержка --enable-run-spool-dir

Если при конфигурировании ejudge была указана опция --enable-run-spool-dir, этот каталог тоже должен быть доступен по сети. Например, при значении опции по умолчанию, каталог может подключаться с помощью команды

sshfs USER@SERVER:/home/ej-run-spool /home/ej-run-spool -o ServerAliveInterval=30,reconnect,allow_other

Кроме того, для запуска ej-super-run на тестирующих компьютерах потребуется указать опцию -p SERVER, чтобы тестирующие процессы забирали запросы на решение из правильной очереди тестирования. Таким образом, строка запуска ej-super-run будет примерно такой:

ej-super-run -m /tmp/super-run -p SERVER

Параллельное тестирование по сети с помощью ej-agent (3.10.0)

Компонент ej-agent упрощает организацию тестирования по сети. Для использования ej-agent необходимо, чтобы для пользователя, под которым выполняется тестирование, был настроен вход по ssh без пароля на сервер ejudge под пользователем ejudge.

Для запуска компиляции и тестирования на хосте достаточно выполнить следующую команду:

ejudge-control --mirror MIRROR-DIR --queue QUEUE-ID --agent ssh:HOST --instance-id INST-ID -s start

• MIRROR-DIR — это локальный каталог, который будет использоваться для кеширования файлов тестов с сервера.
• QUEUE-ID — это имя очереди на сервере. В самом простом варианте имя очереди на сервере совпадает с именем хоста сервера ejudge.
• HOST — это имя хоста сервера ejudge.
• INST-id — это имя данного компьютера. Оно используется на сервере, чтобы различать хосты, на которых выполняется тестирование.

Для останова компиляции и тестирования достаточно выполнить команду:

ejudge-control -s stop

На тестирующих хостах должна быть развернута инсталляция ejudge, включая каталоги конфигурации и турнирова (обычно /home/judges). В этой инсталляции может не быть турниров, но она как таковая должна быть работоспособной.

Кеширование результата компиляции (3.11.0)

Типичный путь поступившего на тестирование файла выглядит следующим образом:

• исходный файл передается через каталоги обмена от ej-contests к ej-compile. Если компоненты находятся на разных хостах, файл копируется по сети.
• после компиляции скомпилированный файл передается через каталоги обмена от ej-compile к ej-contests. Если компоненты находятся на разных хостах, файл копируется по сети.
• скомпилированный файл передается через каталоги обмена от ej-contests к ej-super-run. Если компоненты находятся на разных хостах, файл копируется по сети.

Размер скомпилированного файла может быть весьма большим (несколько мегабайт), например, для программ на kotlin или go, и копирование исполняемого файла по сети туда и обратно может потребовать заметного времени, сравнимого со временем тестирования.

В случае, когда и компонент компиляции ej-compile, и компонент тестирования ej-super-run выполняются на одном и том же хосте, отличном от хоста ej-contests, и только на этом хосте, передавать результат компиляции по сети на сервер ej-contests и обратно не имеет смысла.

В этом случае можно использовать локальное кеширование результатов компиляции. Компонент ej-compile не скопирует файл на сервер, а положит его в локальный каталог, из которого он будет забран компонентом ej-super-run. Локальное кеширование включается с помощью опции --local-cache программы ejudge-control. Например,

ejudge-control --mirror MIRROR-DIR --local-cache CACHE-DIR --queue QUEUE-ID --agent ssh:HOST --instance-id INST-ID -s start

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