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

Question

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

Для этого я использую RegCM4 на основе Linux. Я использую Ubuntu. Самая мощная из имеющихся у нас систем имеет процессор 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 поддерживаемые сетевые карты.
Для целей тестирования я настроил небольшую имитационную работу для анализа 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 = Максимальная скорость 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 как хозяин ---- обратите внимание на порядок.

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

Я также запустил другой набор тестов, на этот раз используя hostfile (с именем 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 ядра для ОС и других операций на отдельных узлах. Почему это происходит?

Answer 1

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

---

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

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

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

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

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

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

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

---

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

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

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

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

Если вы можете изменить код, взгляните на примерытестовых случаев, продемонстрированных в качестве методологии для основного подхода, чтобы изолировать первопричину фактического узкого места и сохранить{ 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 , ЧИСЛА DIMMS, ETC, ETC..ВАШЕ СОДЕРЖАНИЕ МОЖЕТ РАЗЛИЧИТЬ"}

Мне нравится таблица, где видны порядки величин, кто-то может предпочесть визуальную форму, где цвета "смещаются"- парадигма, изначально основанная на посте Питера Норвига:

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

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

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

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