Автор: Майкл Хебенстрейт (Michael Hebenstreit)

Мощь современных высокопроизводительных вычислительных кластеров доступна конечным пользователям главным образом через приложения StarCD* или Fluent* – два типичных инструмента для решения задач вычислительной гидродинамики. Пока кластер работает нормально (или, по крайней мере, в соответствии с ожиданиями), ни инженер, его настраивающий, ни администратор, контролирующий его работу, не знают, что конкретно происходит внутри двоичного программного пакета, производящего все вычисления.

Случается, что кластер работает не так, как хотелось бы. Тогда, чтобы определить действия для устранения неполадок, нужно сначала понять, как работает ваша вычислительная среда. Если вы этого не знаете, то что бы вы ни делали, ваши усилия, скорее всего, пропадут даром. Предположим, вам повезло, и вы сумели устранить неполадки. В этом случае вы все равно будете беспокоиться о том, как долго будут действовать принятые вами меры. В этой статье будет рассмотрен комплект инструментов Intel Cluster Tools, а именно – его компоненты Intel Trace Collector, Intel Trace Analyzer и Intel MPI Benchmarks, с помощью которых вы сможете определить верную последовательность действий для решения своей проблемы.

Однажды к автору этой статьи обратился клиент, который был недоволен производительностью своего кластера Hewlett-Packard (HP)* на базе процессоров Intel® Itanium® 2 с частотой 1,5 ГГц, на котором производились вычисления в StarCD. Узлы кластера подключались через коммутатор к гигабитной сети Ethernet. Оказалось, что эффективность 32-разрядных вычислений кластера была чересчур низка, причем не достигались даже результаты тестирования, проведенного перед приобретением кластера. Во время визита к клиенту автор определил, что проблемой являлась недостаточная загрузка процессоров в узлах кластера (около 60% вместо нормальных 95-100%).

Затем автор договорился с клиентом о проведении простого тестирования с обработкой таблицы с четырьмя миллионами ячеек, не содержащих интеллектуальную собственность. Низкие результаты тестирования подтвердили, что проблема заключается в аппаратном, а не в программном обеспечении. Однако автор и представители компании Hewlett-Packard были готовы подтвердить, что подобная проблема не возникала на аналогичных серверных системах, установленных в офисах корпорации Intel и компании HP.

Поскольку зависимость производительности кластера от типа тестов отсутствовала, автор предположил, что все дело в сетевом оборудовании. Поэтому он занялся анализом коммуникационной среды StarCD с помощью утилит Intel Trace Collector (ITC) и Intel Trace Analyzer. К счастью, нашлась совместимая с ITC версия StarCD. Поскольку поведение этой программы зависит только от набора обрабатываемых ею данных и конкретной версии, с помощью StarCD можно протестировать любое аппаратное обеспечение. Системные задержки будут зависеть от аппаратного обеспечения, а задержки в коммуникационной среде – нет. Тестирование проходило с учетом трех обстоятельств:


1. StarCD использует несколько вызовов связи (см. рис.) – даже в рамках 0,1 с потоки обмениваются данными


2. Основная функция интерфейса передачи данных – вызов от каждого к каждому


3. Распределение загрузки по 13 узлам неравномерно, но вполне достаточно для того, чтобы кластер работал с эффективностью не менее 90%

Изложенные выше обстоятельства позволяют проводить тестирование интерфейса передачи данных и обнаружить проблемы, не зависящие от StarCD. Для тестирования использовался набор эталонных тестов Intel MPI, результаты которого заслуживают доверия. Измеренная задержка на кластере HP при отправке сообщения от каждого – к каждому размером в 35 кБ составила приблизительно 3 мкс.


Результаты аналогичного тестирования, проведенного на кластере клиента, были непостоянны и не превышали 50% максимально возможной производительности (основной результат на рисунке).

Изменения в конфигурации коммутатора ничего не изменили (результат изменение конфигурации коммутатора).


Проблема нашлась только тогда, когда автор решил проверить кабельную сеть кластера. Оказалось, что 63 кластерных узла были подключены к пятипортовому коммутатору. Для проведения вычислений обычно требовалось от 8 до 16 узлов (по 2 процессора в каждом), например, от первого до шестнадцатого. Из информации на рисунке можно видеть, что при такой конфигурации данные проходили только через один или два порта, что перегружало коммутатор.


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

Углубленный анализ структуры сообщений поможет пользователю понять, сообщения какого размера вызывают самые большие временные задержки в кластере. К сожалению, подобная возможность пока не реализована в Intel Trace Analyzer, однако такие данные можно получить, изучив файлы отчетов. Для этого после запуска программы проведите конвертирование данных в формат ASCII с помощью утилиты xstftool из состава Intel Trace Collector:

       xstftool FILE.stf --dump

На экран будут выведены примерно следующие данные:

       1998984 EXCHEXT CPU 0:1 DOWNTO "MPI:MPI_Bcast"
       1998984 GLOBALOP MPI_Bcast ON 0:1 COM COMM_WORLD(2) ROOT 1 SENT 4 
             RECVD 0 DURATION 499
       1999149 EXCHEXT CPU 0:3 UPTO "Application:User_Code"

В первой строке – время создания файла, а остальные строки не требуют комментариев. Итак, в нашем случае был обработан вызов размером в 4 кБ, от приложения к MPI_Broadcast группы 0, потока 1 – к четырем получателям, в течение 499 тактов. Запрос вернулся приложению (см. строку 3).


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

Чтобы найти зависимость задержки при вызовах MPI_alltoall calls от размера сообщения, автор проанализировал результаты тестирования StarCD.

Оказалось, что около 40% времени занимают сообщения малого размера, а еще 40% – сообщения с размером более 100 кБ.


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

Выводы

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

Случай, описанный в статье, показывает, как пользователи и системные администраторы могут применить комплект Intel Cluster Tools для решения своих повседневных задач. Пользователи определят, равномерно ли распределяется нагрузка по узлам кластера, а администратор будет знать о загрузке сети программой StarCD и о влиянии сетевого уровня среды на производительность. Помните, что ни сверхпроизводительные процессоры, ни большой объем оперативной памяти не сделают ваш кластер эффективным, если его сеть является узким местом.

С помощью набора эталонных тестов Intel MPI администратор может моделировать поведение приложения быстрее, чем при анализе производительности StarCD, который может быть затруднен при поиске оптимальных методов решения проблем (например, как в случае с настройкой сети на физическом уровне).

Сведения, представленные в статье, не являются интеллектуальной собственностью и могут распространяться свободно. Это особенно важно для IT-инфраструктур, в которых функции администрирования выполняют сотрудники сторонних организаций.

Администрирование современных высокопроизводительных вычислительных систем становится массовой потребностью, причем каждая такая система по-своему уникальна и имеет собственные проблемы. Одним из комплектов инструментов, предназначенных для решения таких проблем, является Intel Cluster Tools.

We invite you to post a comment (not monitored by customer support) on this page or send a question directly to our support team.