Замедление вычислений на сервере при интенсивном использовании ОЗУ

У меня проблема с замедлением работы сервера в очень специфическом сценарии. Факты таковы:

1) Использую вычислительное приложение WRF (Weather Research and Forecast)
2) Я использую Dual Xeon E5-2620 v3 с 128 ГБ ОЗУ (архитектура NUMA - вероятно, связана с проблемой!)
3) Я запускаю WRF с mpirun -n 22 wrf.exe (у меня доступно 24 логических ядра)
4) Я использую Centos 7 с ядром 3.10.0-514.26.2.el7.x86_64
5) Все работает нормально с точки зрения вычислительной производительности, пока не произойдет одно из следующих событий:
5a) кеш файла linux получает некоторые данные, или
5б) Я использую tmpfs и заполняю его какими-то данными

В сценариях 5a или 5b мой WRF начинает внезапно замедляться, а иногда даже в ~ 5 раз медленнее, чем обычно.

6) Оперативная память не меняется местами, это даже близко не происходит, у меня около 80% ОЗУ свободно в худшем случае!
7) vm.zone_reclaim_mode = 1 в /etc/sysctl.conf, похоже, немного помогает отложить проблему в сценарии 5a
8) echo 1> / proc / sys / vm / drop_caches полностью решает проблему в сценарии 5a, восстанавливает производительность WRF до максимальной скорости, но только временно, пока кеш файлов снова не получит данные, поэтому я использую эту команду в cron (не волнуйтесь, это нормально, я использую компьютер только для WRF, и ему не нужен файловый кеш для работы на полной скорости)
9), но приведенная выше команда по-прежнему ничего не делает в сценарии 5b (когда я использую tmpfs для временных файлов)
10) perfomanace восстанавливается в сценарии 5b, только если я вручную очищаю tmpfs
11) Это не проблема WRF или mpi
12) Это происходит только на этом одном типе компьютеров, и я администрирую многие из них для одинаковых / аналогичных целей (WRF). Только у этого есть полная архитектура NUMA, поэтому я подозреваю, что в этом что-то есть
13) Я также подозреваю, что в ядре RHEL что-то есть с этим, но я не уверен, еще не пытался переустановить в другой дистрибутив
14) параметры numad и numactl для вызова mpirun, такие как "numactl -l", не имели никакого значения

Дайте мне знать, если у вас есть идея попытаться избежать этих замедлений.

Одна идея пришла мне в голову после того, как я перешел по некоторым «связанным» ссылкам по этому вопросу. Могут ли прозрачные огромные страницы быть источником этой проблемы? Некоторые статьи настоятельно предполагают, что THP плохо работает в системах NUMA.

Я предлагаю включить службу numad:

yum install numad
systemctl enable numad
systemctl start numad

Numad должен иметь возможность автоматически заботиться о локализации памяти. Ситуация, когда процесс выполняется на ЦП первого узла NUMA, однако его данные находятся в ОЗУ, локальном для второго узла NUMA, больше не должно происходить (если только объем необходимой памяти не превышает емкость ОЗУ, локального для одного узла NUMA).

Я также предлагаю настроить настроенную службу с профилем, который лучше всего соответствует вашему сценарию использования. Вам нужно будет измерить различия и выбрать лучшее (или вы можете создать несколько вариантов).

Возможно, я нашел причину странного поведения на вашем узле. Я искал mpirun и нашел страницу руководства:

https://www.open-mpi.org/doc/current/man1/mpirun.1.php

Там написано:

Краткое резюме

Если вы просто ищете, как запустить приложение MPI, вы, вероятно, захотите использовать командную строку следующей формы:% mpirun [-np X] [--hostfile] Это запустит X копий в вашей текущей среде выполнения окружение (если он работает под поддерживаемым менеджером ресурсов, mpirun Open MPI обычно автоматически использует соответствующий стартер процесса менеджера ресурсов, в отличие, например, от rsh или ssh, которые требуют использования файла хоста, или по умолчанию будет запускать все X копий на локальном хосте), планирование (по умолчанию) циклически по слотам ЦП. См. Остальную часть этой страницы для получения более подробной информации.

Обратите внимание, что mpirun автоматически связывает процессы с начала серии v1.8. При отсутствии дополнительных директив используются три шаблона привязки:

Привязка к ядру: когда количество процессов <= 2

Привязать к сокету: когда количество процессов> 2

Нет привязки: при превышении лимита подписки

Если ваше приложение использует потоки, вы, вероятно, захотите убедиться, что вы либо вообще не привязаны (указав --bind-to none), либо привязаны к нескольким ядрам, используя соответствующий уровень привязки или определенное количество обрабатывающих элементов для каждого процесса приложения. .

В вашем случае с n = 22 привязка не применяется, и потоки могут быть перемещены. Вы можете попробовать привязку к внешнему процессору (например, с набором задач). Придется поэкспериментировать.