[mephi-hpc] Вопрос/предложение по кластеру.

anikeev at ut.mephi.ru anikeev at ut.mephi.ru
Mon Mar 30 23:05:37 MSK 2020


Никита Дубинец писал 2020-03-29 02:05:
> Добрый вечер, администраторы и
> пользователи кластера МИФИ.

Добрый вечер!

> У меня есть 2 вопроса/предложения по
> кластеру:
> 
> 1) Могли бы Вы выделить в руководстве
> пользователя фразу: "ТАКИМ ОБРАЗОМ,
> АППАРАТНОЕ ОБЕСПЕЧЕНИЕ ПОЗВОЛЯЕТ
> ЗАПУСКАТЬ ДО 32 THREADS НА КАЖДОМ 16-CORE NODE
> БЕЗ ПЕРЕКЛЮЧЕНИЙ КОНТЕКСТА.", или
> добавить пример, в котором будут
> указан вариант с максимально (в
> большинстве случаев) эффективным
> вариантом запуска задачи на 1 ноде:
> #SBATCH --nodes=1
> 
> #SBATCH --tasks-per-node=32
> Просто в данный момент (когда нагрузка
> существенно сократилась) на кластере
> Черенков сложилась такая ситуация,
> что задачи все равно находятся в
> очереди, в то время как большинство
> нод занято лишь на 50%.

Запуск двух вычислительных потоков на одном ядре без Hyper-Threading 
приводит к переключениям контекста и вызывает падение производительности 
на порядки. Запуск двух вычислительных потоков на одном ядре с HT 
вызывает вымывание кэшей процессора, т.к. размер кэша остается прежним, 
но через него проходит двукратный поток данных. Для большинства HPC 
алгоритмов это приводит к падению производительности в разы. Однако, 
существует группа алгоритмов, которые либо нечувствительны к кэшам, либо 
реализующие обработку одних и тех же данных из кэша обоими потоками ядра 
с HT. На таких алгоритмах HT может давать прирост производительности до 
двух раз, но только в том случае, если эти потоки используют разные 
блоки процессора. Для HPC такие алгоритмы не характерны - львиная доля 
операций проводится одним и тем же блоком AVX/FMA и, как правило, 
настраивается под конкретный размер кэша. Best-practice в HPC является 
отключение HT на аппаратном уровне в BIOS/EFI. На кластерах МИФИ HT 
доступен при явном указании пользователем. Использование HT не 
рекомендуется, пока не проведены тесты производительности приложения с 
HT и без HT.

При реализации чтения одних и тех же данных из кэша лучше подходит 
OpenMP (--tasks-per-node=16 --cpus-per-task=2), MPI btl self 
(--tasks-per-node=32) будет ухудшать вымывание более тяжелыми 
метаданными.

> 2) Очень часто на аналогичных
> вычислительных кластерах в других
> организациях стоит ограничение на
> число нод для 1 пользователя. В случае
> когда необходимо протестировать
> именно многопоточность программы, то
> данное ограничение убирается для
> конкретной задачи, но в остальных
> случаях оно включено. Не стоит ли
> добавить такую функцию на кластеры
> МИФИ (к примеру, ограничение в 4 ноды на
> пользователя). Мне самому довольно
> неловко, когда я запускаю
> квантово-химические расчеты для
> нескольких систем в одном скрипте, и
> они загружают большой процент
> ресурсов кластера.

К сожалению, в общественном доступе есть только один кластер с 
неблокирующей сетью (Черенков, IB FDR), позволяющий решать крупные 
задачи. Если разбить его на части, решение крупных задач станет 
невозможным в принципе. На Unicluster и Basov такие ограничения имеются:

anikeev at master.unicluster ~ $ cat /var/spool/maui/maui.cfg
...
USERCFG[DEFAULT]    MAXPROC=64

Численные значения этих ограничений можно обсудить и изменить.

При выборе размера параллельной задачи стоит в первую очередь 
ориентироваться на кривую масштабирования. Если задача масштабируется 
хорошо, она займет больше ресурсов, но и быстрее их освободит. Если 
задача масштабируется плохо, её лучше запускать в последовательной 
версии (либо с числом потоков менее критического).

> Заранее прошу прощения, если такие
> вопросы и предложения уже были, или
> кто-то воспримет это на свой счет.
> Спасибо, Никита.
> 

С уважением,
инженер отдела UNIX-технологий,
Аникеев Артем.

> --
> 
> Best regards,
> 
> Nikita O. Dubinets
> WEB: Dubinets.me [1]
> 
> PHONE, WHATSAPP, TELEGRAM: +7 903 229-07-01 (Russia)
> PHONE: +1 765 409-27-53 (USA)
> 
> SKYPE: Nikita Dubinets
> 
> 
> 
> Links:
> ------
> [1] http://Dubinets.me
> _______________________________________________
> hpc mailing list
> hpc at lists.mephi.ru
> https://lists.mephi.ru/listinfo/hpc



More information about the hpc mailing list