search

HPCHub / benchmarks

Technical market research of HPC Cloud vendors
0 stars 0 forks source link

Интегрировать General Tests в Runner #4

Open vbitner87 opened 6 years ago

vbitner87 commented 6 years ago

Надо интегрировать: OSU, NAS, HPCC Инструкция тут: https://github.com/HPCHub/benchmarks/wiki Все вопросы к @mickvav

vbitner87 commented 6 years ago

@tismagilov Создан vSC на 2 узла под тест. Доступ на мастер: admin@37.252.120.118:4116 авторизация по ключу privatekey_openssh.txt privatekey_putty.txt

доступ на узлы с мастера: ssh n001 ssh n002

Инструкция на всякий случай: https://github.com/HPCHub/tutorials/wiki/Quick-start:-vSC-(RUS)

vbitner87 commented 6 years ago

@tismagilov как движется процесс? есть ли какие-то эстимации? нужна ли помощь?

tismagilov commented 6 years ago

@mickvav на узле n001 прописывается не правильный путь к библиотекам mpi: echo $LD_LIBRARY_PATH /usr/mpi/gcc/openmpi-1.10.3rc4/lib вместо /usr/mpi/gcc/openmpi-1.10.3rc4/lib64

Наверное в образе (?) нужно поправить модульфайл: /etc/modulefiles/mpi/openmpi-1.10.3rc4-x86_64

mickvav commented 6 years ago

@gentoorion , а где и как хранятся, администрируются и правятся образы и/или скрипты для их генерации?

tismagilov commented 6 years ago

@mickvav на узле n001 не хватает библиотеки /usr/mpi/gcc/openmpi-1.10.3rc4/lib64/libmpi_usempi.so.1, которая лежит в /usr/lib64/openmpi/lib/libmpi_usempi.so.1 на управляющем узле.

Кроме того, версии Open MPI на управляющем и n001 различаются: 1.10.3rc4 и 1.10.0 Скорее всего это не играет большой роли, но, на мой взгляд, как-то не правильно.

gentoorion commented 6 years ago

а где и как хранятся, администрируются и правятся образы и/или скрипты для их генерации? -- пока нигде, образы создавались руками. Потом руками же модифицировались. ресурсов на создание скриптов для скручивания образов не было. Есть только скрипт чистки образа после снапшота, чтобы с него можно было потом гарантировано пустить новый кластер.

gentoorion commented 6 years ago

на узле n001 не хватает библиотеки /usr/mpi/gcc/openmpi-1.10.3rc4/lib64/libmpi_usempi.so.1, которая лежит в /usr/lib64/openmpi/lib/libmpi_usempi.so.1 на управляющем узле. -- на управляющем узле и на счетном узле openmpi могут различаться. Строго говоря на счетном openmpi не особо нужен. Там все равно нет IB, оттуда только можно задачи пускать, и то это вызывает проблемы. Но он там есть из-за поддержки PBS. Поэтому действительно версии могут слегка отличаться ибо при (пере)сборке версии могли быть не корректно заданы. В основе всех этих сборок openmpi лежит openmpi-1.10.3rc4 из комплекта Mellanox OFED 3.3 . А самый последний openmpi с поддержкой SGE, PBS и актуальных для нас драйверов Mellanox есть на access:/root/mpi/openmpi-sge-pbs-1.10.3rc4-1.33100.x86_64.rpm . Должен стоять везде он. Могли переткнуть случайно или старый мелланоксовский или даже из репозитория Centos дернуть (врядли).

tismagilov commented 6 years ago

@gentoorion проблема с не правильным путем к библиотекам mpi ещё актуальна. Если руками не поправить modulefile, то ни одно mpi приложение не работает.

tismagilov commented 6 years ago

@mickvav Возможно ли в файл платформы добавить переменные: MPICC, MPIF77, MPIF90 (т.е. отделить их от gcc, icc и т.п.)

mickvav commented 6 years ago

Возможно, и думаю, стоит. Пока - сделал в духе which mpicc. Доделать бы - при следующих прогонах, проверить и откорректировать, на каких платформах оно работает.

tismagilov commented 6 years ago

@mickvav Как я могу видеть, сейчас предпологается, что в платформ файле используется фиксированное число узлов. Правильно ли я понимаю, что для запуска на 1,2,4,...,n узлов необходимо создать соответствующее число platform файлов? Верно ли, что рамках скрипта run.sh можно изменять только количество процессов на узле?

mickvav commented 6 years ago

Да, сейчас так. Конкретно для penguin я сделал общую заготовку и отдельные вариаты с разным числом узлов.

tismagilov commented 6 years ago

@mickvav В таком случае нужно выработать структуру лога так, чтобы по имени платформы, дате и времени я мог получить логи запусков на всех имеющихся конфигурациях узлов (1,2,4,8 и т.д. ) Сейчас получается, что каждой платформе соответствует заданное число узлов ... а внутри может быть большое число запусков в разное (условно случайное) время. Можно конечно это делать скриптом, которому нужно будет явно указывать, где лежат логи данной системы с заданным числом узлов. Этот вариант плох, т.к. при увеличении числа узлов стока для анализа результатов будет пропорционально удлиняться

tismagilov commented 6 years ago

@mickvav Или эта парадигма не противоречит возможности запуска в рамках конфигурации с 4-я узлами на 2 и 1 узлах. Правда тогда каша какая-то получается.

mickvav commented 6 years ago

Предлагаю договориться о нотации имён платформ. Например, так: Имя платформы всегда начинается с имени семейства (hpchub, amazon, azure, penguin ...), Если в имени встречается конструкция вида, к примеру 4-nodes мы понимаем, что это 4 узла. Ещё будет, вероятно, разделение по CPU и , возможно, каким-то еще параметрам, но предлагаю это обсуждать уже по мере поступления задач.

tismagilov commented 6 years ago

@mickvav В зависимости от использования OPENMP нужно менять политику привязки MPI процессов (не к ядру, а к группе размером в OMP_NUM_THREADS)

У меня такая мысль: OMP_NUM_THREADS должна определяться в скриптах run.sh (тестов) а не в платформфайле. Тогда функция hpchub_mpirun в зависимости от того, определена или нет переменная OMP_NUM_THREADS может выбирать политику привязки.

mickvav commented 6 years ago

Ок, пожалуй соглашусь. Только наверное так: Платформа может проставить OMP_NUM_THREADS в число, соответствующее максимальному числу эффективно работающих OpenMP-нитей на данной платформе. Но не должна в hpchub_mpirun предполагать, что это число осталось тем же, так как run-файл может (но не обязан!) его уменьшить. Грубо говоря, если на платформе только 4 ядра, глупо в тесте заводить 6 нитей - почти наверняка работать будет хуже, чем на 4-х.