Отладка узких мест производительности
Если вы используете высокопроизводительное вычислительное приложение (HPC) на большом количестве виртуальных машин (более 16), рекомендуется начать выполнение меньшей проблемы на меньшем количестве виртуальных машин. Этот тест проверяет, работает ли приложение HPC должным образом.
Не предполагайте, что только потому, что вы работаете параллельное приложение HPC, время его стены (истекшее реальное время) продолжает уменьшаться при запуске на дополнительных виртуальных машинах (с более параллельными процессами). На самом деле для многих тесно связанных приложений HPC время по часам может увеличиваться при попытке запустить их на других виртуальных машинах.
Это может происходить по нескольким причинам. Например:
Вы можете реализовать параллельный алгоритм неэффективно.
Размер проблемы, который является размером модели или количеством градусов свободы (NDOF), недостаточно велик. Так как приложение выполняется с помощью большего числа параллельных процессов, объем вычислений, выполняемых каждым процессом, слишком мал. В результате время обмена данными между параллельными процессами доминирует общее время стены. Увеличение времени взаимодействия приводит к увеличению общего времени по часам.
Важно знать, насколько хорошо приложение HPC масштабирует размер проблемы, в котором вас интересуют. Затем можно определить приемлемую эффективность параллелизма с точки зрения производительности и затрат.
Следующая формула параллельного ускорения позволяет определить, насколько хорошо производительность параллельных приложений повышается по мере добавления параллельных процессов:
$${\text{параллельное ускорение}} = {\dfrac{\text{фактическое время (1 процесс)}}{\text{фактическое время (количество процессов)}}}$$
Следующая формула эффективности параллельных вычислений иллюстрирует эффективность использования вычислительных ресурсов при добавлении дополнительных процессов для повышения производительности параллельных приложений:
$${\text{эффективность параллельных процессов}} = {\dfrac{\text{параллельное ускорение}}{\text{количество процессов}}}$$
Если вы не уверены в производительности параллельного масштабирования для тесно связанных приложений HPC, выполните исследование масштабирования. Другими словами, запустите приложение на 1, 2, 4, 8, 16 и т. д., параллельные процессы. Вычислите ускорение и эффективность параллельных процессов, а затем, на основе этих результатов, примите решение, сколько параллельных процессов вы хотите использовать.
Перед выполнением заданий рекомендуется отключить все ненужные службы, которые могут оказать влияние на параллельное масштабирование, например, агент Linux для Azure. После завершения заданий можно повторно включить службы. Эта рекомендация особенно актуальна, если вы используете все доступные ядра и выполняете масштабирование до большого количества виртуальных машин.
Чтобы остановить агент Linux для Azure, выполните следующую команду:
sudo system stop waagent.service
Проверки производительности
Ниже приведена информация о некоторых базовых проверках, помогающих выявить потенциальные проблемы с производительностью.
Убедитесь, что на каждой виртуальной машине запущено правильное количество процессов и потоков.
Простой способ определить, используете ли вы правильное количество процессов и потоков на каждой виртуальной машине, чтобы получить среднее значение нагрузки системы на каждой виртуальной машине с таким средством, как время простоя. Полученное количество процессов и потоков должно приблизительно соответствовать общему ожидаемому количеству процессов и потоков на каждой виртуальной машине. Если записанное среднее значение нагрузки меньше или выше ожидаемого общего количества процессов и потоков, это указывает на проблему, которая должна быть исправлена.
Необходимо тщательно проверить аргументы интерфейса передачи сообщений (MPI) и указать количество параллельных потоков. Например, проверьте аргументы командной строки приложения или проверьте значения переменных среды, например OMP_NUM_THREADS.
Убедитесь, что процессы и потоки распределены равномерно по всем доменам узлов NUMA.
Если вы используете верхний или htop-инструмент, вы можете выбрать представление домена узла NUMA, указав 2 в качестве параметра командной строки доступ к памяти (NUMA). (Например, для HB120_v2 в этом представлении должно быть 30 доменов узлов NUMA.)
Процент пользовательских процессов должен быть равномерно распределен среди всех доменов NUMA. Если это не так, проверьте аргументы командной строки MPI и переменные среды.
На следующем рисунке показаны выходные данные средства top Linux в представлении NUMA. В данном случае каждый узел NUMA используется на 50 процентов.
Проверка состояния выполнения процессов и потоков
Чтобы проверить состояние выполнения процессов и потоков, следует использовать средство top. В идеальном случае все процессы и потоки должны находиться в запущенном состоянии (R).
Если некоторые или все процессы и потоки находятся в состоянии непрерывного спящего режима (D) или спящего режима (S), необходимо исследовать ситуацию, чтобы понять причину. В зависимости от алгоритма приложения нахождение процессов и потоков в состоянии сна может быть нормальным и ожидаемым. Однако это может указывать на ограничение ресурсов, например нехватку производительности ввода-вывода из-за используемого решения хранилища.
В следующей формуле показано, насколько эффективно работает параллельное приложение, если оно ожидает некоторых системных ресурсов (таких как операции ввода-вывода) и какой степени:
$${\text{время ожидания приложения}} = {\text{фактическое время}} - \left( {\dfrac{\text{Общее время ЦП для всех параллельных процессов }}{\text{Количество параллельных процессов}}} \right)$$
Проверка того, ограничено ли приложение операциями ввода-вывода
Процессы и потоки тратят значительное количество времени в неинтерпретируемый спящий режим (D) или спящий режим (S) может быть индикатором того, что есть узкие места ввода-вывода, которые необходимо исследовать. Некоторые приложения HPC в рамках своих выходных данных позволяют профилировать производительность. Эти профили показывают процент времени, затраченного на выполнение операций ввода-вывода и скорость операций ввода-вывода для чтения и записи. Эти показатели также могут указывать на узкие места ввода-вывода.
Если вы не знаете, где выполняются операции ввода-вывода, можно использовать такие средства, как iostat. Чтобы убедиться, что у вас возникла проблема с вводом-выводом, измените решение хранилища на то, что вы знаете быстрее, чем то, что вы использовали. Затем повторно запустите приложение HPC. Например, можно использовать быстрый локальный SSD-диск NVMe или электронный диск.
После внесения этого изменения задайте себе следующие вопросы: Вы видите какое-либо улучшение во времени ввода-вывода? Увеличилось ли общее фактическое время? и если да, то как часто.
Проверка того, ограничено ли приложение по сетевым возможностям
Определите процент общего времени по часам, который приложение затрачивает на взаимодействие между процессами (обычно это взаимодействие MPI).
Если ваше приложение ограничено по сетевым возможностям, следует убедиться, что вы используете сеть InfiniBand при запуске приложения HPC. Если доступна гибридная параллельная версия, следует определить, сокращается ли время на взаимодействие по сети.
Если у вас есть доступ к исходному коду, следует проверить, существуют ли более эффективные способы реализации взаимодействия. Например, используйте коллективные операции вместо точки к точке или попробуйте использовать асинхронное взаимодействие вместо синхронного.