RegCM, MPICH, кластеризация компьютеров

Предыстория: мне нужно выполнить огромные вычисления для моделирования климата с более чем 800 [GB] данными (за последние 50 лет и будущие 80 лет).

Для этого я использую RegCM4 на основе Linux. Я использую Убунту. Самая мощная система, которая у нас есть, имеет процессор Intel XEON с 20 ядрами. Также у нас есть почти 20 менее мощных восьмиядерных процессоров Intel i7 меньшего размера.

Для запуска симуляций одной системы потребуется больше месяца.

Итак, я пытался настроить компьютерные кластеры с доступными ресурсами.
(К вашему сведению: RegCM допускает параллельную обработку с mpi.)

Характеристики::

Computer socket cores_per_socket threads_per_core CPUs   RAM   Hard_drives 
node0    1      10               2                20   32 GB   256 GB  + 2 TB-HDD
node1    1       4               2                 8    8 GB             1 TB-HDD
node2    1       4               2                 8    8 GB             1 TB-HDD

-> Я использую mpich v3 (точный номер версии не помню)

И так далее... (все узлы, кроме node0, такие же, как node1.)
Все узлы имеют 1 Gbps поддерживаемые карты Ethernet.
Для проверки я создал небольшой моделирование работы для анализа 6 дней климата. Во всех тестовых симуляциях использовались одни и те же параметры и настройки модели.

Все узлы загружаются со своих собственных жестких дисков.
node0 работает на Ubuntu 16.04 LTS.
на других узлах работает Ubuntu 14.04 LTS.

С чего я начал? Я выполнил шаги, описанные в здесь.

  1. Соединил node1 и node2 кабелем Cat 6, присвоив им статические IP-адреса. (пока оставил node0) - отредактировал /etc/hosts с IP-адресами и соответствующими именами - node1 и node2 как указано в таблице выше
  2. настроить вход без пароля с ssh в обоих - успех
  3. создал папку в /home/user в node1 (которая будет главной в этом тесте) и экспортировал папку ( /etc/exports ), смонтировал эту папку через NFS в node2 и отредактировал /etc/fstab в node2 - успех
  4. Прогнал мой regcm по кластеру, используя 14 ядер обеих машин - успешно
  5. Я использовал: iotop, bmon, htop для контроля чтения/записи диска, сетевого трафика и использования ЦП соответственно.

$ mpirun -np 14 -hosts node0,node1 ./bin/regcmMPI test.in

Результат этого теста
Более быстрые вычисления по сравнению с обработкой одного узла


Теперь я попробовал то же самое с node0 (см. характеристики компьютера выше)

-> Я работаю над SSD в node0.
-> работает нормально, но проблема связана с фактором времени при подключении в кластере.

Вот сводка результатов: - сначала использовалось только node0 - без использования кластера

$ mpirun -np 20 ./bin/regcmMPI test.in

nodes   no.of_cores_used    run_time_reported_by_regcm_in_sec   actual time taken in sec (approx)
node0   20                  59.58                                60
node0   16                  65.35                                66
node0   14                  73.33                                74

это нормально

Теперь, используя кластер
(используйте следующую ссылку, чтобы понять таблицу ниже):

rt = Время работы процессора, указанное regcm, в секундах

a-rt = фактическое время в секундах (приблизительно)

LAN = Максимальная достигнутая скорость локальной сети (прием/отправка) в МБ/с

disk(0 / 1) = Максимальная скорость записи на диск при node0/при node1 в МБ/с

nodes*  cores   rt      a-rt    LAN     disk(  0 /  1 )
1,0    16       148     176     100/30        90 / 50
0,1    16       145     146      30/30         6 /  0
1,0    14       116     143     100/25        85 / 75
0,1    14       121     121      20/20         7 /  0

*Примечание:

1,0 (например, для 16 ядер) означает: $ mpirun -np 16 -hosts node1,node0 ./bin/regcmMPI test.in

0,1 (например, для 16 ядер) означает: $ mpirun -np 16 -hosts node0,node1 ./bin/regcmMPI test.in

Фактическое время выполнения было рассчитано вручную с использованием времени начала и окончания, сообщаемого regcm.

Выше мы видим, что использование локальной сети и скорость записи на диск значительно различались для двух вариантов: 1. передача node1,node0 в качестве хоста; и 2. передача node0,node1 в качестве хоста ---- обратите внимание на порядок.

Также время работы на одном узле меньше, чем на кластере. Почему?

Я также провел еще один набор тестов, на этот раз с использованием хост-файла (с именем hostlist), содержимое которого было следующим:

node0:16
node1:6

Теперь я запустил следующий скрипт

$ mpirun -np 22 -f hostlist ./bin/regcmMPI test.in

Сообщалось о времени работы ЦП 101 [s], фактическое время работы составляло 1 min 42 sec ( 102 [s] ), достигнутая скорость локальной сети составляла около 10-15 [MB/s], скорость записи на диск составляла около < сильный>7 [MB/s].

Наилучший результат был получен, когда я использовал ту же настройку файла хоста и запускал код с 20 процессорами, таким образом, недоподписываясь

$ mpirun -np 20 -f hostlist ./bin/regcmMPI test.in

CPU runtime     : 90 [s]
Actual run time : 91 [s]
LAN             : 10 [MB/s]

Когда я изменил число ядер с 20 на 18, время работы увеличилось до 102 [s].

Я не еще не подключил node2 к системе.


Вопросы:

  1. Есть ли способ добиться более высокой скорости вычислений? Я делаю что-то неправильно ?
  2. Время вычислений для одной машины с 14 ядрами меньше, чем для кластера с 22 или 20 ядрами. Почему это происходит?
  3. Какое оптимальное количество ядер можно использовать для достижения эффективности по времени?
  4. Как добиться наилучшей производительности с доступными ресурсами?
  5. Есть ли какое-нибудь лучшее руководство по использованию mpich, которое может ответить на мои вопросы? (такой информации не нашел)
  6. Иногда использование меньшего количества ядер дает более быстрое время завершения, чем использование более мощных ядер, хотя я не использую все доступные ядра, оставляя 1 или 2 ядра для ОС и других операций на отдельных узлах. Почему это происходит?

person anup    schedule 01.12.2017    source источник
comment
В одной сложной теме много вопросов, и ответить на них конкретно можно только при наличии глубоких знаний о RegCM. Звучит так, будто вы работаете в академических кругах — я бы порекомендовал вам обратиться в ваш региональный центр высокопроизводительных вычислений. У них гораздо больше подходящих аппаратных ресурсов, и они умеют их эффективно использовать.   -  person Zulan    schedule 01.12.2017
comment
В целом: я настоятельно рекомендую избегать использования гетерогенных систем (например, узлов с разными версиями ОС, ЦП). В вашей настройке: отключите node0.   -  person Zulan    schedule 01.12.2017
comment
спасибо за ваш ответ, @Zulan, конечно, глубокие знания о RegCM были бы лучше для ответа на вопрос (вопросы). Я запускаю эти симуляции для своей диссертации. И я не думаю, что смогу попасть в центр HPC, я не знаю ни одного такого центра в Непале. Я использовал node0, потому что это была лучшая доступная система, и я, конечно же, хотел использовать доступный ресурс. Также я считал, что добавление еще одного ТБ SSD ускорит запись на диск и, следовательно, сократит время.   -  person anup    schedule 04.12.2017
comment
Кроме того, я также попытался упростить ответы на свои вопросы, исключив RegCM из уравнения. Я считаю, что решения, которые я ищу для проблем, с которыми я столкнулся, больше связаны с физическим расположением кластера и, в частности, с mpi. Спасибо, что уделили время.   -  person anup    schedule 04.12.2017


Ответы (1)


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


ВВЕДЕНИЕ:
Упрощенные ответы на вопросы о скрытой сложной системе:

1:
Есть ли способ добиться более высокой скорости вычислений?
Да.< br> Я делаю что-то неправильно?
Не напрямую.

2:
Время вычислений для одной машины с 14 ядрами меньше, чем для кластера с 22 или 20 ядрами. Почему это происходит?
Вы платите больше, чем получаете. Это просто. NFS - распределенная по сети абстракция файловой системы возможна, но вы платите огромные деньги за простоту ее использования, если производительность становится конечной целью. В целом, вся совокупная сумма всех видов дополнительных затрат (распределение данных + высокие дополнительные накладные расходы) превышает чистый эффект [PARALLEL]-распределяемой рабочей нагрузки, разделенной на но небольшое количество CPU_cores, появляется фактическое замедление вместо ускорения. Это общий главный подозреваемый (не говоря уже об отключении гиперпоточности в BIOS как таковом для интенсивных вычислений).

3:
Какое оптимальное количество ядер можно использовать для достижения эффективности времени?
Сначала определите самый большой процесс. -узкое место наблюдается{ CPU | MEMORY | LAN | fileIO | a-poor-algorithm }, следующий только поиск лучшего шага для повышения скорости (продолжайте итеративное продвижение вперед в этой { cause: remedy }-цепочке, пока производительность все еще растет) . Никогда не пытайтесь идти в обратном порядке.

4:
Как добиться наилучшей производительности с доступными ресурсами?
Это наиболее интересно и потребует дополнительной работы ( ссылку ниже).

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

6:
Иногда использование меньшего количества ядер дает более быстрое время завершения, чем использование большего количества ядер, хотя я не использую все доступные ядра, оставляя 1 или 2 ядра для ОС и других операций на отдельных узлах. Почему это происходит?
Ref. [ пункт 2 выше ]


РЕШЕНИЕ.
Что всегда можно сделать с этой дилеммой дизайна?

Прежде чем делать какие-либо дальнейшие шаги, постарайтесь хорошо понять оба исходных закона Амдала< /strong> + его новая строгая переформулировка накладных расходов

Без освоения этой основы ничто другое не поможет вам решить дилемму-охоты-за-производительностью-( двойственность )-справедливого-отчета-оба-{ -costs +benefits }

Узкое представление:
предпочитаю тесты предположениям. ( +1 за выполнение тестов )
mpich – это инструмент для распространения вашего кода, а также для управления всеми связанными процессами и синхронизацией. Несмотря на то, что симуляция погоды может иметь четко установленную локализацию влияния (обязательным является меньшее количество межпроцессного взаимодействия и синхронизации, но фактический код определяет, сколько из них действительно происходит), тем не менее, затраты на передачу данных будут преобладать (см. ниже). на порядок). Если вы не можете изменить код, вам придется с этим смириться, и вы можете просто попытаться изменить аппаратное обеспечение, которое является посредником в потоке (от интерфейса 1 Гбит/с до коммутационных сетей 10 Гбит/с или 40 Гбит/с, если тесты бенчмаркинга поддержите это и позволит бюджет).

Если вы можете изменить код, взгляните на образцы тестовых случаев, продемонстрированные в качестве методологии. для принципиального подхода к изоляции основной причины фактического узкого места и сохранению итераций { cause: remedy, ... } в качестве метода исправления того, что может стать лучше.

Более широкий обзор:

Сколько времени потребуется, чтобы прочитать ( N ) блоков из 0.8 [TB] файла на диске и get ( N - 1 ) из них, только что отправленных по локальной сети?

Для приблизительной оценки давайте освежим в памяти несколько фактов о том, как эти вещи на самом деле работают:

           0.5 ns - CPU L1 dCACHE reference
           1   ns - speed-of-light (a photon) travel a 1 ft (30.5cm) distance
           5   ns - CPU L1 iCACHE Branch mispredict
           7   ns - CPU L2  CACHE reference
          71   ns - CPU cross-QPI/NUMA best  case on XEON E5-46*
         100   ns - MUTEX lock/unlock
         100   ns - own DDR MEMORY reference
         135   ns - CPU cross-QPI/NUMA best  case on XEON E7-*
         202   ns - CPU cross-QPI/NUMA worst case on XEON E7-*
         325   ns - CPU cross-QPI/NUMA worst case on XEON E5-46*
      10,000   ns - Compress 1K bytes with Zippy PROCESS
      20,000   ns - Send 2K bytes over 1 Gbps NETWORK
     250,000   ns - Read 1 MB sequentially from MEMORY
     500,000   ns - Round trip within a same DataCenter
  10,000,000   ns - DISK seek
  10,000,000   ns - Read 1 MB sequentially from NETWORK
  30,000,000   ns - Read 1 MB sequentially from DISK
 150,000,000   ns - Send a NETWORK packet CA -> Netherlands
|   |   |   |
|   |   | ns|
|   | us|
| ms|

Процессоры сильно различаются по своей основной внутренней (на самом деле NUMA) архитектуре:

Core i7 Xeon 5500 Series Data Source Latency (approximate)               [Pg. 22]

local  L1 CACHE hit,                              ~4 cycles (   2.1 -  1.2 ns )
local  L2 CACHE hit,                             ~10 cycles (   5.3 -  3.0 ns )
local  L3 CACHE hit, line unshared               ~40 cycles (  21.4 - 12.0 ns )
local  L3 CACHE hit, shared line in another core ~65 cycles (  34.8 - 19.5 ns )
local  L3 CACHE hit, modified in another core    ~75 cycles (  40.2 - 22.5 ns )

remote L3 CACHE (Ref: Fig.1 [Pg. 5])        ~100-300 cycles ( 160.7 - 30.0 ns )

local  DRAM                                                   ~60 ns
remote DRAM                                                  ~100 ns

Тем не менее, несмотря на то, что эти опубликованные Intel подробные данные влияют на любое и все планирование производительности, эти цифры не предоставлены и не являются постоянными, как Intel предупреждает в опубликованном примечании:

"ПРИМЕЧАНИЕ: ЭТИ ЗНАЧЕНИЯ ЯВЛЯЮТСЯ ГРУБЫМИ ПРИБЛИЖЕННЫМИ. ОНИ ЗАВИСЯТ ОТ ЯДЕРНЫХ И НЕЯДЕРНЫХ ЧАСТОТ, ПАМЯТИ, СКОРОСТЕЙ, BIOS НАСТРОЙКИ, КОЛИЧЕСТВО DIMM И Т.Д., И Т.П..ВАШ ПРОБЕГ МОЖЕТ ОТЛИЧАТЬСЯ."

Мне нравится таблица, в которой видны порядки величин, кто-то может предпочесть визуальную форму, в которой цвета «меняют» парадигму, первоначально основанную на сообщении Питера Норвига: https://i.stack.imgur.com/  a7jWu.png

Если бы мой бюджет, сроки и программное обеспечение для моделирования позволяли, я бы предпочел (с точки зрения производительности, из-за маскирования задержки и обработки на основе локальности данных) перейти без слоя mpich на максимальное количество каналов ЦП + MEM-контроллера на ЦП.

Здравый смысл для архитектурно-оптимизированного проектирования обработки показал, что те же самые результаты могут быть получены в чистом-[SERIAL]-коде где-то даже ~50x ~ 100x быстрее, чем в лучшем случае в "исходном" коде или при использовании «наивных» инструментов программирования кремниевой архитектуры и неправильных парадигм.

Сегодня системы способны обслуживать обширные потребности моделирования таким образом, не тратя больше, чем получено.

Надеюсь, что и ваши условия позволят вам с умом подойти к этому направлению, ориентированному на производительность, и сократить время выполнения симуляций до менее чем месяца.

person user3666197    schedule 01.12.2017
comment
Я могу себе представить, как трудно получить замечательную квоту на обработку, если и сроки, и бюджет идут против вас - не думайте так! В областях, где я работал, получение вычислительных мощностей начального уровня не требует денег и усилий. Например, потратить 1 час на написание простого предложения о 50 тысячах бесплатных процессорных часов, которые вы получите в течение 2 дней, — это вполне возможно. Конечно, я не могу говорить за каждый центр высокопроизводительных вычислений, но обычно они хотят поддерживать высокую загрузку и научную производительность. - person Zulan; 02.12.2017
comment
Что касается вашего ответа, я чувствую, что могу дать вам хорошее общее представление, но в целом он слишком общий и упрощенный для конкретной проблемы, с риском скатиться к предположениям. Конечно, лучший ответ вряд ли возможен без фактического анализа воспроизводимой производительности и глубоких знаний RegCM. - person Zulan; 02.12.2017
comment
Не могу подтвердить 1-е замечание. Да, есть инициативы по увеличению мощностей высокопроизводительных вычислений. Это может создать ложную иллюзию создания избыточного предложения в HPC-классе [CPU.hrs] и что это может позволить большему количеству заданий HPC получить теперь запасную [CPU.hrs]-квоту от (теперь уже устаревающих) предыдущих поколений HPC. - ткань, так как высокоприоритетные рабочие места HPC размещаются на новейших игрушках. Но есть и противоположный рабочий процесс вывода из эксплуатации HPC-оборудования старых поколений (сети | кластеры), на который HPC-центры не желают тратить энергию и оплачивать счета за электроэнергию, поскольку в дело вступают более производительные процессоры) - person user3666197; 02.12.2017
comment
Спасибо @user3666197 за ваши усилия. Упрощенные ответы вверху были более полезными. Поможет ли отключение гиперпоточности? Потому что программа RegCM (чей исходник я, конечно, изменить не могу) была разработана для поддержки гиперпоточности для параллельной обработки и даже кластеризации. Однако нет доступных ресурсов для помощи в настройке кластера. Они предполагают, что у нас уже есть сетевые администраторы для этой работы. Что касается узкого места, я не думаю, что Ethernet со скоростью 1 Гбит / с является одним из них, максимальная достигнутая скорость локальной сети составляла 100 Мбит / с, и это было максимальное значение. В остальное время скорость LAN была ограничена 20-30. - person anup; 04.12.2017
comment
Использование памяти было не слишком высоким, 32 ГБ ОЗУ, казалось, были крутыми, с использованием примерно 60%. FileIO может быть проблемой. Как я упоминал в вопросе выше (третья табличная запись и примечание под ней), скорость записи на диск менялась в зависимости от порядка узлов, который я указывал в команде. Я не могу определиться с этим, так как запись была сделана на NVMe SSD (должен быть M.2). RegCM, вероятно, не имеет плохого алгоритма. Он был разработан ICTP, и тысячи исследователей используют его по всему миру. Я считаю, что эффективное использование нескольких ядер решит проблему, но это только то, что я думаю. - person anup; 04.12.2017
comment
HyperThreading может помочь в случае, если плохие операции ввода-вывода допускают такой прием чередования потока процессов CPU_core (который может помочь частично или полностью замаскировать задержки задержки ввода-вывода), но всегда за счет известной стоимости неуправляемой потери кеша CPU_core перед -извлекаемые данные, что означает разрушенную (недостаточную) производительность вычислений с привязкой к процессору. Таким образом, соотношение затрат и эффектов делает HT всегда скорее абсолютным злом для производительности HPC :о) - person user3666197; 08.12.2017