CC BY
24
УДК 004.724.3:004.772:519.255:519.687.1
А.Н. Сальников, Д.Ю. Андреев2, Р.Д. Лебедев3
ИНСТРУМЕНТАЛЬНАЯ СИСТЕМА ДЛЯ АНАЛИЗА ХАРАКТЕРИСТИК КОММУНИКАЦИОННОЙ СРЕДЫ ВЫЧИСЛИТЕЛЬНОГО КЛАСТЕРА НА ОСНОВЕ ФУНКЦИЙ СТАНДАРТА MPI*
В статье обсуждаются вопросы, связанные с особенностью поведения коммуникаций в современных вычислительных кластерах с большим числом процессорных элементов при передаче сообщений. Авторами предлагается развитие подхода измерения характеристик на основе синтетических MPI-тестов. Для анализа особенностей предлагаются средства визуализации и алгоритм кластеризации выходных данных MPI-тестов. Разработанная инструментальная система позволяет обнаруживать такие особенности, как влияние внешних помех на скорость передачи данных, топологическую структуру коммуникаций, а также некорректную работу узлов вычислительного кластера. В статье приводятся данные по кластерам: СКИФ-60 "Чебышев", СКИФ Т500+ "Ломоносов", "МВС-ЮОК", BlueGene/P.
Ключевые слова: MPI, вычислительный кластер, анализ производительности, системное администрирование.
1. Введение. На сегодняшний день существует уже достаточно большое число кластерных установок с числом процессорных элементов больше 1000. К таким установкам в России можно отнести: "МВС-ЮОК" (МСЦ РАН), "Чебышев" (НИВЦ МГУ), "BlueGene/P" (ВМК МГУ), "Ломоносов" (НИВЦ МГУ), "СКИФ-Аврора" (ЮУрГУ) и т.д. Информация о наиболее производительных установках (суперкомпьютерах) собрана в ежегодно обновляемые списки top50 (http://supercomputers.ru) по России и top500 (http://www.top500.org) по всему миру. Все эти установки используются в основном для задач математического моделирования физических, химических, экономических и других процессов. Основным средством написания программ для таких установок является одна из библиотечных реализаций стандарта MPI (Message Passing Interface) [1]. Существенной проблемой при написании программ на MPI для вычислительных кластеров является величина задержки при передаче MPI-сообщения. Чем большее число процессоров присутствует в вычислительном кластере, тем большее время может требоваться на передачу данных от одного MPI-процесса к другому и тем большая неоднородность в величине задержек будет наблюдаться при передаче сообщений. Такая ситуация обусловлена ростом сложности устройства коммуникационной подсистемы вычислительного кластера с увеличением числа процессорных элементов.
Часто производители предоставляют информацию о коммуникационной среде многопроцессорной системы, указывая ее топологию. Примерами такой топологии являются двумерный или трехмерный тор, решетка или трехмерный куб. В каждой из этих топологий для вычислительного узла определено понятие соседнего узла. Физически несколько соседних узлов могут находиться в разных серверных стойках, тем самым оказывая влияние на время передачи данных. Полная спецификация архитектуры многопроцессорной системы может быть недоступна пользователю, что делает чрезвычайно трудоемким решение задачи априорного предсказания задержки при обмене данными между процессорами.
В текущий момент активно развивается направление по созданию набора искусственных MPI-тестов, предназначенных для выявления особенностей поведения коммуникаций и оценки производительности вычислительных кластеров. Результаты тестирования могут быть использованы системными администраторами для обнаружения проблемных узлов кластера. Авторами данной статьи разрабатывается программное средство подобного рода, предназначенное для тестирования и анализа коммуникационной среды вычислительного кластера.
1 Факультет ВМК МГУ, ст. научн. сотр., к.ф.-м.н., e-mail: salnikovQcs.msu.su
2 ВЦ РАН, асп., e-mail: andreevdQcs.msu.su
3 НИЯУ МИФИ, студ., e-mail: rmn.lebedevQgmail.com
* Работа выполнена в рамках Федеральной целевой программы "Научные и научно-педагогические кадры инновационной России" (государственные контракты № П1258, № П1317, № П1367), а также при поддержке грантов РФФИ 11-07-00614-а, 11-07-00161-а.
К средствам, которые осуществляют тестирование коммуникаций на основе посылки сообщений, можно отнести: NetPIPE [2], SKaMPI [3], MPIBlib [4], MPIbenchsuit [5], Intel MPI Benchmarks [6].
Также на сегодня доступны статьи по сравнению коммуникаций различных кластерных систем средствами MPI, например статья [7]. Следует также подчеркнуть, что в основном средства тестирования коммуникационной инфраструктуры работают в режиме измерения времени при многократной передаче сообщения между фиксированной парой MPI-процессов или от одного MPI-процесса из группы, если используется коллективная операция MPI.
Большинство из этих средств обладает следующими недостатками.
• Часто в них отсутствуют сложные режимы измерения задержек, которые предполагают некоторое заданное поведение не только измеряемых MPI-процессов, но и остальных, не участвующих в измерении. Это важно для получения целостной картины об особенностях коммуникационной среды вычислительного кластера.
• В пакеты тестирования коммуникационных сред могут быть не включены средства визуализации и анализа полученных данных. Наличие подобных инструментов становится принципиально важным при тестировании вычислительных кластеров с очень большим числом процессоров, где объем полученных данных уже не допускает возможности ручного анализа, а требует для своей обработки специальных программных средств.
С целью устранения указанных выше недостатков коллективом авторов как часть проекта PARUS [8] ведется разработка собственной инструментальной системы для анализа пропускной способности коммуникаций вычислительного кластера networkJestsê. Инструментальная система доступна для скачивания в исходных кодах (см. [9]).
Стоит отметить, что все эти недостатки были подмечены не только авторами статьи, но и еще группой авторов в США ("Sandia National Laboratories"). Сотрудниками данной лаборатории поддерживается проект с открытым исходным кодом "Cbench" [10]. Целью проекта является объединение уже имеющихся средств тестирования в единую интегрированную систему, которая позволит извлекать дополнительную информацию о вычислительной системе. Компонентами Cbench служат Intel MPI Benchmarks, Nas Parallel Benchmarks [11], STREAM [12], High Performance Linpack [13] (эти системы служат скорее для оценки затрат времени выполнения при решении определенного класса вычислительных задач). Тест STREAM упоминается в статье [14] в связи с проблемой эффективности доступа в память, известной под именем "проблема стены памяти". Также в состав Cbench входят некоторые другие системы тестирования, в частности системы тестирования операций чтения/записи в распределенную файловую систему, например Lustre [15]. Cbench с помощью набора Perl скриптов осуществляет запуск этих компонент с различным набором параметров и в разных комбинациях на узлах вычислительной системы.
Однако Cbench, в отличие от networkJestsê в проекте PARUS, не концентрируется именно на особенностях коммуникационной среды и, похоже, не содержит своих собственных средств визуализации. В дальнейшем, вероятно, будет разумно интегрировать networkJestsê в качестве одного из компонентов Cbench. Рассмотрим более подробно network Jests 2.
2. Описание инструментальной системы. Разрабатываемая инструментальная система состоит из нескольких компонент.
• Система тестов (приложение network Jest).
• Конвертеры, которые осуществляют перевод результатов тестирования в форматы: "текстовое представление", "некластеризованое NetCDF-представление", "кластеризованное NetCDF представление" .
• Алгоритм кластеризации, который осуществляет сжатие данных.
• Средства визуализации результатов тестирования, реализованные как два приложения, одно из которых написано на Java, а другое на С++ с использованием библиотеки Qt4.
Предполагается, что сначала будут запущены тесты, результат выполнения которых будет сохранен в файловой системе как набор текстовых или NetCDF файлов. Процесс тестирования построен таким образом, что промежуточные результаты доступны с интерфейсной машины кластера. Полученные промежуточные или окончательные результаты можно направить на вход алгоритму кластеризации.
Реализация алгоритма кластеризации может работать на интерфейсной машине суперкомпьютера или любой другой машине, которая имеет доступ к файловой системе того суперкомпьютера, на котором производилось тестирование. Сжатые алгоритмом кластеризации данные могут быть переписаны на машину пользователя, после чего пользователь сможет осуществлять их визуализацию с помощью программ, разработанных авторами.
2.1. Описание метода тестирования коммуникаций. Авторами на языке программирования С разработано приложение network-test, которое использует функции стандарта MPI-2 для осуществления передачи данных между отдельными процессорными элементами вычислительного кластера. Пропускная способность коммуникационной среды вычисляется на основе многократных измерений величин задержек, которые возникают при использовании той или иной MPI-функции в фиксированном в параметрах приложения network-test режиме. На основе многократных измерений определяются такие характеристики, как максимальная величина задержки, минимальная величина задержки, среднее арифметическое всех задержек, стандартное квадратичное отклонение.
На вход приложению поступают следующие параметры: type — тип/режим тестирования; begin — начальная длина сообщения; end — конечная длина сообщения; step — шаг приращения длины сообщения; num.iterations — число итераций на один шаг по длине сообщения; file — шаблон имен файлов для сохранения результатов тестирования; некоторые дополнительные параметры, которые зависят от режима тестирования. На выходе приложение создает набор NetCDF-файлов, которые имеют следующий стиль именования: имя_тгп.пс, имя_аьегаде.пс и т.д.
Приложение начинает свою работу с длиной сообщения begin, затем на каждом шаге увеличивает длину на величину step и останавливается по достижении порога end. Для исполняющегося на кластере MPI-приложения на каждый шаг по длине сообщения рассматриваются все возможные сочетания пар MPI-процессов. Для каждой пары (¿,j), независимо от других пар MPI-процессов, но в соответствии с режимом тестирования, производятся измерения задержек на MPI-функциях. Величина задержки обычно фиксируется для процесса j. Таким образом на каждый шаг current length по длине сообщения создается вектор матриц значений задержек. Размерность вектора определяется числом итераций на каждый шаг по длине сообщения. Для каждого такого вектора вычисляются статистические характеристики, значения которых сохраняются в файлы с результатами. Таким образом в файле хранятся вычисленные статистические характеристики. Характеристики хранятся как элементы трехмерного пространства с координатами (i,j, currentJength), где begin ^ currentJength ^ end.
Для хранения результатов тестирования разработан NetCDF-формат хранения данных. CDL-заголовок для данного формата приведен далее:
netcdf info { dimensions:
х = <количество процессоров> ; у = <количество процессоров> ; n = UNLIMITED ;
int begin_mes_length. ; */ int end_mes_length ; int step_length. ; int noise_mes_length ; int num_noise_mes ; int num_noise_proc ; int num_repeates ; double data(n, x, y) ; //data - матрицы, содержащие результаты теста.
variables:
int proc_num ; int test_type ; int data_type ;
/*
* Информация о типе теста
* и его параметрах
}
В приведенном образце СБЬ-заголовка используется \о! С1)К-ич.\10|>0ние. которое не ограничено по длине сообщения. Это важно, поскольку процесс тестирования может оказаться весьма длительным,
и приложение будет досрочно завершено системой ведения очередей задач пользователей, что приведет к недописанному файлу. Введение неограниченного измерения в NetCDF-файле позволяет корректным образом обработать эту ситуацию в процессе чтения файлов с результатами. Параметр data_type в NetCDF-файле определяет тип хранимой статистической характеристики.
Остановимся теперь на режимах тестирования, которые можно указать приложению network-test.
2.2. Режимы тестирования коммуникаций. В текущей реализации приложения network-test доступно 9 различных режимов тестирования. Все они направлены либо на выяснение обстоятельств поведения коммуникаций при разных уровнях нагрузки, в том числе пиковых, либо на исследование эффективности реализации определенной MPI-функции. Нагрузка создается искусственно за счет особого способа организации вызовов MPI-функций. Особая ситуация в коммуникациях вычислительного кластера также может быть смоделирована специальным порядком вызовов MPI-функций. За счет сравнения результатов от разных режимов тестирования можно сделать некоторые выводы, например, какие MPI-функции в каких ситуациях выгоднее использовать. Бегло рассмотрим эти режимы.
• Режим one_to_one. Здесь выбирается пара MPI-процессов (i,j). Между ними инициируется передача сообщения с помощью блокирующего вызова MPLSend со стороны процесса i и прием сообщения процессом j с помощью блокирующего вызова MPLRecv. Гарантируется, что остальные MPI-процессы приложения в этот момент "молчат". Так перебираются все пары MPI-процессов в соответствии с методикой, представленной выше. Этот режим показывает максимальную пропускную способность каналов связи в коммуникационной среде вычислительного кластера. В случае пар вида (г, г) в качестве величины задержки принимается 0.
• Режим async_one_to_one. В целом он аналогичен режиму one_to_one, но процессы используют функции MPIJsend и MPLIrecv таким образом, что в коммуникациях организуется два противоположным образом направленных потока данных. Если здесь возникает существенная разница во времени с one_to_one, то можно говорить, что канал между двумя процессорными элементами, на которые распределились MPI-процессы, не является полнодуплексным. Это может свидетельствовать как о неправильном дизайне коммуникационной среды, так и о каких-то проблемах, связанных с неисправностями оборудования.
• Режим all_to_all. В отличие от предыдущих режимов, когда все процессы, кроме двух выбранных, "молчали", здесь все процессы одновременно начинают "говорить". Это достигается следующим образом. Каждый MPI-процесс запускает неблокирующий MPIJsend ко всем остальным MPI-процессам, в том числе и к себе самому, а затем MPIJrecv от всех MPI-процессов, в том числе от себя самого. После этого в цикле по числу MPI-процессов запускается функция MPLWaitany, которая сигнализирует о завершении обмена (i,j). Величина задержки определяется по времени между инициализацией первого MPIJsend и выходом из MPLWaitany после соответствующего MPIJrecv. Этот режим может быть использован для определения поведения коммуникаций в состоянии "стресса" (см. рис. 1,6), поскольку в коммуникациях возникает огромный объем данных, передаваемый сразу во всех направлениях.
• Режимы test_noise и test_noise_blocking. Эти режимы являются комбинациями режимов all_to_all и one_to_one. MPI-процесс с порядковым номером 0 на коммуникаторе MPI_COMM_WORLD разделяет все процессы на три непересекающиеся группы — "целевые процессы", "молчащие процессы" и "шумящие процессы". С помощью функции MPLBcast всем процессам рассылается информация об их ролях. Для каждой пары "целевых процессов" вычисляется задержка на вызове MPLRecv (для test_noise_blocking), подобно режиму one_to_one. "Шумящие процессы" выбираются случайно. Они имитируют фоновую загруженность сети, посылая "шумящие" сообщения по схеме взаимодействия, схожей с all_to_all.
• Режимы put_one_to_one и get_one_to_one. Эти режимы тестируют возможность прямого обращения в память удаленного процесса, которая была добавлена в стандарт MPI-2. Процесс может положить свои данные с помощью функции MPLPut в оговоренное заранее место в памяти удаленного MPI-процесса таким образом, что другой процесс не производит никаких действий для отслеживания статуса операции и вообще не будет знать, как много таких операций было произведено. Парной операцией к MPLPut является операция MPLGet, с помощью которой можно "подсмотреть" память другого MPI-процесса. Оба рассматриваемых режима устроены схожим образом с режимом one_to_one. Выбирается пара MPI-процессов, где один в этой паре при помощи MPLPut
в г
Рис. 1. Результаты тестирования, а, б", в — отображают матрицы задержек при передаче, г — отображает значение дисперсии
пишет в память другого, а другой ничего не делает, и наоборот: один при помощи MPI_Get читает память другого, а другой ничего не делает. MPI-процессы, не входящие в пару, ничего не делают — "молчат". В идеале на вызовы MPI_Put и MPI_Get приходится меньший объем накладных расходов, чем на обычные MPLSend и MPLRecv. Поэтому задержки на этих вызовах должны быть меньше, однако взамен приходится отслеживать правильный порядок MPLPut и MPLGet, вызывая функцию барьерной синхронизации MPLFence.
• Режим beast. Этот режим предназначен для определения эффективности коллективных операций MPI. Все MPI-процессы по очереди вызывают функцию MPLBcast. В позицию (i,j) матрицы с результатами заносится величина задержки при возвращении из вызова MPLBcast, где i-ш процесс, указанный как root на коммуникаторе MPI, является источником данных, a j-m процесс является приемником данных. В позицию (i,i) записывается время срабатывания функции MPLBcast для процесса, являющегося корнем (root в терминах MPI) на коммуникаторе.
После получения результатов, по завершении работы приложения ne.twork_te.st, возникает необходимость в анализе, полученных данных. Остановимся для начала на системе визуализации результатов тестирования.
2.3. Описание системы визуализации результатов тестирования. Средства визуализации отображают задержки передачи сообщения в виде, изображений в градациях серого цвета. Чем больше, величина задержки, тем цвет ближе, к черному. При выборе, значений задержек, которые, будут соответствовать максимальному белому и черному цветам на изображении, производится нормализация
по выбору пользователя. Нормализация возможна либо к максимальному и минимальному значению в матрице при фиксированной длине сообщения, либо к максимальному и минимальному значению задержки на весь диапазон данных. Пользователю предоставляется возможность самостоятельно изменять уровень белого и черного цвета. Кроме всего прочего предоставляется возможность пересчета максимального и минимального значений для диапазона, задаваемого окном по длине сообщения. Средства визуализации предоставляют несколько режимов отображения данных.
• Режим отображения матрицы задержек при фиксированной длине сообщения. Пример отображения данных в этом режиме показан на рис. 1 ,а.
• Режим отображения строк или столбцов для всех матриц задержек соответстующего диапазона значений длины сообщений. Этот режим может быть использован для анализа того, как взаимно меняется время передачи от одного MPI-процесса к остальным MPI-процессам. Пример отображения в таком режиме показан на рис. 1,в.
• Режим отображения позиции (i,j) для всех значений длины сообщений. Используется для определения характеристик задержек при передаче для фиксированной пары процессоров вычислительного кластера.
2.4. Описание метода кластеризации результатов тестирования. Разработанное средство кластеризации результатов тестирования преследует две цели — автоматическое выделение закономерностей в результатах тестирования и сжатие данных с сохранением быстрого доступа к отдельным значениям. В ходе визуального анализа результатов тестирования, полученных с различных кластеров, было отмечено, что величины задержек на показываемом изображении группируются в некоторые, обычно прямоугольные, области. Причем эти области остаются устойчивыми со сменой длины сообщения в тесте. Этот факт стал причиной создания описываемого далее алгоритма кластеризации.
В рамках одной длины сообщения в тесте кластеризация сводится к выделению близких по значению элементов матрицы. Хранение такой информации сводится к хранению пар (номер элемента матрицы, номер кластера). Однако нас интересует более сложный объект — кластер, который сохраняется на протяжении диапазона длин сообщений. Задача выделения кластеров для диапазона длин сообщений сводится к выделению множеств пар (i,j), где каждое выделенное множество удовлетворяет следующим правилам.
1. Величины задержек для всех пар (i,j), составляющих множество внутри одной матрицы, для фиксированной длины сообщения отличаются не более чем на пороговое значение, задаваемое в параметрах алгоритма.
2. При увеличении длины сообщения значения тех же самых пар (i,j) также отличаются не более чем на то же пороговое значение.
3. Из предыдущего правила допускается не более чем фиксированное в параметрах алгоритма число исключений. При этом не допускается добавление новых пар (i,j), которых не было в первом правиле.
Результатом кластеризации являются диапазоны длин сообщений с выделенными на них множествами (кластерами). Минимально возможный диапазон длин задается параметром алгоритма. По каждой длине сообщения каждое найденное множество представляется одним значением. Это значение вычисляется как среднее арифметическое задержки для всех пар, составляющих множество по рассматриваемой длине сообщения. Результаты кластеризации сохраняются в NetCDF-файле со следующим CDL-заголовком:
netcdf info { dimensions:
х = <количество процессоров> ; i = <количество матриц до кластеризации ; n = UNLIMITED ; d = UNLIMITED ; variables:
int proc_num ; /*
int test_type ; * Информация о типе теста
int data_type ; * и его параметрах
int begin_mes_length ; */
int end_mes_length ;
int step_length ;
int noise_mes_length ;
int num_noise_mes ;
int num_noise_proc ;
int num_repeates ;
int info(n, x, x) ;
//info - матрица, содержащая номер позиции начала экземпляра // кластера, к которому принадлежит пара процессоров (х,у). int length.Cn); // соответствие матрицы п длине сообщения, double data(d) ; // значения экземпляров, описывающих кластеры.
Файл с результатами кластеризации помимо самих величин задержек хранит полную информацию о характеристиках теста. В отличие от файла с ^кластеризованными результатами здесь матрица хранит только номера кластеров для одного из выделенных алгоритмом диапазонов длин. Эти данные сохранены в переменную info. Переменная info хранит столько матриц, сколько диапазонов длины было выделено. Переменная length хранит информацию о началах диапазонов длины. Значения теста, которые описывают выделенные кластеры, хранятся в переменной data.
Такой способ хранения обеспечивает получение любого значения теста (с учетом погрешности кластеризации) за несколько операций.
1. Определение по переменной length номера диапазона, к которому принадлежит искомое значение.
2. Определение по переменной info указателя на кластер, к которому относится искомое значение.
3. Обращение в data за искомым значением.
Сам алгоритм кластеризации достаточно сложен, и его описание несколько громоздко, поэтому здесь оно приведено не будет, а более подробно с ним можно ознакомиться в статье [16].
Автоматический выбор пороговых значений для определения близости значений теста, попадающих в один кластер, и алгоритм выбора минимального размера кластера остаются темой для дальнейших исследований.
3. Результаты и выводы. К настоящему моменту времени программный код был скомпилирован и установлен на таких вычислительных системах, как: "МВС-100К", "Чебышев", "Ломоносов", "BlueGene/P". На этих системах были произведены запуски программы network_test, где были указаны различные режимы тестирования. В связи с невозможностью представить все полученные результаты в данной статье остановимся только на наиболее характерных моментах и наиболее интересных особенностях в коммуникациях, полученных после анализа данных сгенерированных приложением network_test.
Результаты тестирования, обсуждаемые в данной статье, проиллюстрированы на рис. 1 и 2. Изображение на рис. 1 ,а было получено для машины BlueGene/P при тестировании в режиме one_to_one, здесь приведена матрица, полученная при длине сообщения в 1075 байт. Изображение на рис. 1,6 было получено для машины "МВС-100К" для сообщений длиной в 300 байт. Был выбран режим all_to_all. На рисунке видно существенно большее время передачи и приема на одном из узлов кластера по отношению к другим узлам. На рис. 1,в выбран процесс номер 176 и показаны все величины задержек для диапазона длины сообщения при передаче ссобщений от этого процесса ко всем остальным процессам. Длина сообщения на рисунке увеличивается сверху вниз. Неоднородность кластера увеличивается с ростом длины сообщения. Данные приведены для машины "Ломоносов" МГУ. Диапазон длины от 0 до 3600 байт. На рис. 1,г отображено значение дисперсии для режима тестирования one_to_one на машине "Ломоносов" МГУ. Изображение построено для сообщений размером в 9600 байт.
На рис. 2 представлены графики задержек между фиксированными парами MPI-процессов. Здесь собраны результаты тестирования "BlueGene/P" в режиме one_to_one с использованием различного
Рис. 2. Результаты тестирования. Графики задержек для фиксированных пар процессоров
числа процессоров при запуске (128, 256, 512) и с использованием различных режимов функционирования отдельного процессора: 4 MPI-процесса (500 Мб памяти на один процесс), 2 MPI-процесса с возможностью двух потоков на процесс (1 Гб памяти на процесс), 1 MPI-процесс с возможностью четырех потоков (2 Гб памяти на один процесс). В архитектуре BlueGene/P эти режимы реализованы аппаратно.
Особенности поведения коммуникационной среды кластера можно условно поделить на два класса — топологические и особенности, связанные с различного рода пороговыми значениями, которые встроены либо в аппаратуру, либо в программную часть. Программной особенностью может быть, например, смена протокола передачи сообщений в MPI в зависимости от размера сообщения. На рис. 1 представлены топологические особенности, а на рис. 2 — пороговые.
Обсудим для начала топологические особенности. На рис. 1 ,а видна топологическая структура машины "BlueGene/P". Такой вид структуры имеет как общие черты с другими системами, так и отличия. Например, "клеточная" структура универсальна и определяется в целом количеством соседей у узла кластера, а также числом транзитов при передаче. Индивидуальными будут размер и взаимное расположение этих клеточек. Уникальной особенностью "BlueGene/P" по сравнению с остальными рассматриваемыми системами является наличие полос, параллельных главной диагонали. Эти полосы определяются топологией ЗБ-тор, которая в BlueGene/P позволяет избежать деградации скорости передачи для пространственно удаленных процессоров. Для другой популярной топологии "жирное дерево" (на этой топологии построены машины "Ломоносов", "Чебышев", "МВС-100К") наблюдается тенденция увеличения величины задержки по мере удаления от диагонали матрицы.
Казалось бы, топологическая структура для таких систем широко известна общественности, однако есть некоторые нюансы, которые проиллюстрированы на рис. 1,6. Этот рисунок показывает пороговые изменения величины задержки в зависимости от длины сообщения. Эти данные часто приводятся разработчиками средств тестирования, но обычно для индивидуальных пар MPI-процессов, как это сделано на рис. 1,6, 2,а-г. Однако факт увеличения неоднородности коммуникаций и характер
увеличения этой неоднородности обычно не приводится. Как следует из рис. 1, в, фактически для разных длин сообщений мы имеем отличающиеся друг от друга топологии вычислительной системы, что может существенно сказаться на скорости решения задачи пользователя на данной вычислительной системе.
На рис. 1,6,г демонстрируются некоторые топологические особенности, которые напрямую из способа соединения процессоров между собой не следуют. На рис. 1,г показываются значения дисперсии в зависимости от величины задержек при передаче сообщений. Видно, что дисперсия распределена неравномерно по вычислительной системе. Характер распределения дисперсии может зависеть от способа соединения проводов, от настройки операционной системы, от особенностей функционирования коммуникационного оборудования. К сожалению, эту информацию можно получить только после сборки всей вычислительной системы целиком. Затем ее можно учитывать в программе и при назначении задачи пользователя на вычисление.
На рис. 1,6иллюстрируется наличие в системе "сбойного узла". На рисунке показан узел кластера, который по каким-то причинам принимает и передает сообщения существенно медленнее остальных. Это может быть как временным состоянием, например в операционной системе запустилась системная служба, так и постоянным — в гнездо плохо вставлен сетевой кабель или что-то подобное.
Во всех описанных выше случаях средства визуализации позволили увидеть особенности "глазом", не прибегая к сложному изучению больших объемов цифровых данных. А алгоритм кластеризации для машины "Чебышев" позволил сократить объем хранимой информации более чем в 10 раз при сохранении информации о присутствующих особенностях.
Для системы "BlueGene/P" было проведено сравнение задержки при передаче данных между различными процессорами и в разных ситуациях. Устройство "BlueGene/P" таково, что при запуске задаче пользователя назначается некоторый раздел. В случае с "BlueGene/P", установленным на факультете ВМК МГУ, минимальный размер раздела составляет 128 процессоров. При запуске система планирования задач пользователя стремится расположить процессы задачи как можно ближе друг к другу, поэтому при запросе различного числа процессоров в момент постановки задачи в очередь при запуске задачей будут использоваться различные фрагменты топологии многопроцессорной системы.
Из графика на рис. 2,6 видно, что задержки при передаче данных между удаленными и соседними процессорами имеют близкие значения, однако на рис. 2,а время передачи существенно зависит от удаленности процессоров друг от друга. В первом случае было задействовано 512 процессоров, а во втором — 256. Этот эффект объясняется тем, что при использовании раздела с 512 процессорами вычислительная система начинает использовать топологию трехмерного тора, в отличие от трехмерной решетки, которая используется для 128 и 256 процессоров.
Теперь обсудим особенности, связанные с пороговыми значениями. Ступенчатая структура на рис. 2,а,6 связана с изменением алгоритма маршрутизации в реализации MPI при изменении длины сообщения. График на рис. 2,в демонстрирует, что алгоритмы маршрутизации влияют на скорость передачи сообщений даже между ядрами одного процессора. О том, что ступени на графиках соответствуют смене алгоритма маршрутизации сообщений, можно судить по официальному руководству IBM на систему "BlueGene/P" [17].
Разрабатываемую инструментальную систему можно также использовать для сравнения различных вычислительных кластеров между собой. Например, на рис. 2,г приведена величина задержек при передаче сообщений между соседними узлами. Как видно из рисунка, максимальная пропускная способность канала достигается для машины "Ломоносов", однако наименьший разброс в задержках при передаче наблюдается в системе "BlueGene/P".
Итак, по результатам статьи можно сделать следующие выводы. Разработанные средства могут быть полезны системному администратору для обеспечения стабильности работы коммуникационной среды вычислительной системы. Программистам может быть полезна информация о задержках передач данных через коммуникационную среду, что необходимо для оценки общего времени работы создаваемых параллельных программ.
К сожалению, полное тестирование огромных вычислительных систем затруднено. Это связано сразу с целым рядом проблем. Одна из них — это неудовлетворительная работа реализаций MPI в случае использования более чем 4000 процессоров, как это показано в статье [18]. Другая — это большое время тестирования и большой объем данных, получаемый с многопроцессорных систем с таким числом процессоров (в "Ломоносов" на текущий момент их 8892). Все это показывает как важность
работ, проводимых в данном направлении, так и необходимость написания программ, основанных на
новых принципах, которые позволят манипулировать с системами в 20 тыс. и более процессоров.
СПИСОК ЛИТЕРАТУРЫ
1. Message Passing Interface Forum MPI. A Message-Passing Interface Standard. Version 2.2 // Stuttgart: High Performance Computing Center Stuttgart, 2009.
2. Turner D., Chen X. Protocol-dependent messagepassing performance on linux clusters // Proc. of the IEEE Intern. Conf. on Cluster Computing. Washington, USA: IEEE Computer Society, 2002. P. 187.
3. Reussner R., HunzelmanG. Achieving performance portability with SKaMPI for highperformance MPI programs // ICCS '01 Proc. of the Intern. Conf. on Computational Science. LNCS. N 2074. 2001. P. 841-850.
4. Lastovetsky A., Rychkov V., O'Flynn M. MPIBlib: Benchmarking MPI communications for parallel computing on homogeneous and heterogeneous clusters // Proc. of the 15th European PVM/MPI Users' Group Meeting on Recent Advances in Parallel Virtual Machine and Message Passing Interface. LNCS. 2008. N 5205. P. 227-238.
5. http://parallel.ru/testmpi
6. http://software.intel.com/en-us/articles/intel-mpi-benchmarks
7. Majumder S., Rixner S. Comparing ethernet and myrinet for MPI communication // LCR 2004 7th Workshop on Languages, Compilers, and Run-Time Systems for Scalable Computers. Houston, USA: Association for Computing Machinery, 2004. P. 83-90.
8. Salnikov A.N. PARUS: A parallel programming framework for heterogeneous multiprocessor systems // Proc. of the 15th European PVM/MPI Users' Group Meeting on Recent Advances in Parallel Virtual Machine and Message Passing Interface. LNCS. N 4192. 2006. P. 408-409.
9. http://parus.sf.net
10. http://sourceforge.net/apps/trac/cbench
11. Bailey D.H., Barszcz E., Barton J.T. et al. The NAS parallel benchmarks//Intern. J. of Supercomp. Applications. 1991. 5. N 3. P. 66-73.
12. http://streambench.org
13. Dongarral J. J., Luszczek P., Petitet A. The LINPACK benchmark: past, present and future//CCPE. 2003. 15. N 9. P. 803-820.
14. McKee S. A. Reflections on the memory wall // Proc. of the 1st conf. on computing frontiers. N.Y., USA: Association for Computing Machinery, 2004. P. 162-167.
15. Weikuan Y., Vetter J., Canon R.S., et al. Exploiting Lustre file joining for effective collective IO//7th IEEE Intern. Symp. on Cluster Computing and the Grid. Los Alamitos, USA: IEEE Computer Society, 2007. P. 267-274.
16. Сальников A.H., Андреев Д.Ю. Средство автоматической кластеризации результатов тестирования коммуникаций в многопроцессорных системах // Труды всероссийской суперкомпьютерной конференции "Научный сервис в сети Интернет: масштабируемость, параллельность, эффективность". М.: Изд-во МГУ, 2009. С. 293-297.
17. Sosа С., Knudson В. IBM System Blue Gene Solution: Blue Gene/P Application Development. Mountain View, USA: Vervante, 2009.
18. Balaji P., Buntinas D., Goodell D. et al. MPI on a million processors // Proc. of the 16th European PVM/MPI Users' Group Meeting on Recent Advances in Parallel Virtual Machine and Message Passing Interface. LNCS. N 5759. 2009. P. 20-30.
Поступила в редакцию 18.04.11
A MPI BASED TOOLKIT FOR HPC CLUSTER INTERCONNECT ANALYSIS
Salnikov A. N., Andreev D. Yu., Lebedev R. D.
This article highlights exigencies of developers and system administrators to features of High Performance Computational cluster's interconnect which becomes actual on messages transfer where large number of processing elements are used. The authors hold on a way of investigations where features of cluster's interconnect are extracting by means of a set of synthetic MPI-tests. The features are analyzed with clustering algorithm and tools of visualizing which are apply to the output of MPI-tests. Software which allows disclose a hidden topology of cluster interconnect, influence of noises to the delays during data transfer and cluster's nodes what are working abnormally have been developed by authors of this article. The supercomputers SKIF-60 "Chebishev", SKIF T 500+ "Lomonosov", "MVS-100K" and BlueGene/P have been investigated by this software.
Keywords: MPI, interconnect analysis, cluster administrating, benchmarks, communications testing.
