English translation is not available yet. Showing Russian content.
Профилировать network congestion на 64 GPU
ТЕХНИЧЕСКОЕ ЗАДАНИЕ: Профилировать network congestion на 64 GPU
1. Цель задачи
Научиться профилировать сетевую нагрузку в кластере из 64 GPU (8 узлов × 8 GPU) с InfiniBand, выявлять горячие точки (hot spots) с помощью инструментов perfquery и ibdiagnet, измерять влияние на all-reduce и уменьшать утилизацию сети. Задача развивает навыки низкоуровневой диагностики InfiniBand и оптимизации коллективных операций в HPC/NVIDIA DGX-like системах.
Ключевой результат Утилизация сети (средняя загрузка портов узлов) во время all-reduce снижена с >85% до <70%, документация hot spots и рекомендации.
2. Исходные данные
| Что нужно | Откуда взять |
|---|---|
| Кластер 64 GPU (8 узлов × 8 GPU, NVLink + InfiniBand HDR 200Gb/s) | Реальный тестовый стенд или облачная симуляция (см. ниже) |
InfiniBand инструменты (perfquery, ibdiagnet, ibstat, ibswitches, ibroute) | Пакет infiniband-diags (обычно предустановлен на узлах с Mellanox) |
| Бенчмарк all-reduce | NCCL-tests (собрать из исходников на каждом узле) |
| Python 3.8+ с библиотеками | Анализ логов: pandas, matplotlib, seaborn |
| Среда для визуализации топологии | Graphviz (dot) или вывод ibdiagnet -o topo |
Если нет реального кластера — симулируем:
- Развернуть 8 виртуальных машин (Ubuntu 22.04) с сетевым мостом, имитирующим InfiniBand (например, Soft-RoCE или эмуляция через ip link add с лимитом пропускания 10G).
- Установить на каждую ВМ пакет
infiniband-diags(не все команды будут работать, но ibstat, ibswitches, ibroute эмулировать можно). - Для генерации трафика использовать iperf3 в режиме множественных потоков — запустить на всех ВМ all-to-all или all-reduce-like паттерн (через скрипт на Python с subprocess).
- Собрать псевдо-логи perfquery, сгенерировав файлы со случайными значениями (но направленными — один порт перегружен). Это даст навык парсинга и анализа.
3. Технологический стек
| Компонент | Инструменты | Назначение |
|---|---|---|
| Сеть | InfiniBand HDR (Mellanox ConnectX-6/7) | Целевое оборудование |
| Диагностика IB | ibdiagnet, perfquery, ibstat, ibswitches, ibroute, ibstatus | Сбор статистики портов, топологии, счетчиков ошибок |
| Бенчмарк | NCCL-tests (sendrecv, all_reduce_perf) | Генерация нагрузки all-reduce |
| Симуляция (опционально) | softiwarp, iperf3, Python, docker-compose | Имитация кластера при отсутствии железа |
| Анализ | Python + pandas, matplotlib, seaborn, networkx | Парсинг логов, визуализация графа, построение heatmap |
| Визуализация топологии | Graphviz, ibdiagnet -o topo | Карта сети с горячими точками |
4. Этапы выполнения
Этап 1: Подготовка окружения и сбор baseline (45-60 минут)
Действия
-
Проверить доступность InfiniBand адаптеров на каждом узле
ibstat # на каждом из 8 узловУбедиться, что все порты активны (State: Active, Physical: LinkUp). Записать GUID портов.
-
Установить/обновить
infiniband-diagssudo apt-get install infiniband-diags -
Собрать NCCL-tests
На каждом узле (или одной копии, затем скопировать бинарники через mpi или pdsh):git clone https://github.com/NVIDIA/nccl-tests.git cd nccl-tests make MPI=1 MPI_HOME=/usr/lib/x86_64-linux-gnu/openmpi # пример для OpenMPI -
Измерить baseline утилизации сети без нагрузки
Запустить ibdiagnet и perfquery для записи исходных счётчиков:ibdiagnet -o all -c # генерирует .csv и диаграммы в /var/log/ibdiagnet/ perfquery -x -P -G <lid_порта> # снять счётчики с одного портаСохранить вывод в
baseline/. -
Запустить all-reduce для загрузки сети
На одном из узлов (например, master) запустить MPI-задачу:mpirun --hostfile hosts.txt -np 64 ./build/all_reduce_perf -b 128M -e 8G -f 2 -n 10 -w 5где
hosts.txtсодержит IP всех 8 узлов × 8 процессов.
Ожидаемый результат этапа
- ibdiagnet output с начальными значениями.
- Лог perfquery до нагрузки.
- Утилизация сети >85% (зафиксировать точное значение).
Этап 2: Сбор data во время all-reduce (30-40 минут)
Действия
-
Запустить фоновый сбор perfquery
Написать скриптcollect_perf.sh, который каждые 5 секунд снимает счётчики со всех активных портов (8 узлов × 1 порт) и пишет в CSV с timestamp:#!/bin/bash while true; do ts=$(date +%s) for node in node1 node2 ... node8; do ssh $node "perfquery -x -P -G <local_port_guid> 2>/dev/null" | awk -v ts="$ts" -v node="$node" '{print ts, node, $0}' done sleep 5 done -
Параллельно запустить all-reduce (как в этапе 1)
mpirun --hostfile hosts.txt -np 64 ./build/all_reduce_perf -b 128M -e 8G -f 2 -n 10 -w 5 & -
После завершения all-reduce остановить сбор (Ctrl+C).
Накопленные данные склеить в один CSV-файл (например, perf_allreduce.csv). -
Собрать ibdiagnet с нагрузкой
ibdiagnet -o all -c -l /tmp/ibdiagnet_loaded
Ожидаемый результат этапа
- CSV с временными рядами счётчиков портов (packets sent, packets rcvd, errors, CRC errors, link down).
- Дамп
ibdiagnet_loaded/с топологией и состояниями. - Лог вывода all_reduce_perf (время, пропускная способность).
Этап 3: Анализ собранных данных и выявление hot spots (1-1.5 часа)
Действия
-
Парсинг CSV perfquery (Python)
Считать CSV, построить heatmap средней загрузки порта (packets per second) для каждого порта во времени. Определить порты, где загрузка >90% (potential hot spots). -
Анализ ошибок и повторных передач
import pandas as pd df = pd.read_csv('perf_allreduce.csv', names=['ts','node','port','xmit','recv','errors','crc','link_down']) summary = df.groupby('node')[['xmit','errors','crc']].agg(['mean','max']) print(summary[summary['errors']['mean'] > 0]) -
Построение графа InfiniBand (интеграция с ibdiagnet)
ibdiagnet -o topo -l /tmp/ibdiagnet_loadedНайти файл ibdiagnet.topo.txt или .dot. Визуализировать с dot -Tpng ibdiagnet.topo.dot -o topo.png.
Наложить тепловую карту на граф: окрасить узлы/линки в соответствии с загрузкой из анализа perfquery. -
Идентификация hot spots
- Порты с близкой к линейке пропускной способностью (200Gbps) при all-reduce.
- Линки с CRC error count > 0 (физические проблемы).
- Узлы, где загрузка порта дисбалансна (один порт >90%, соседний <30%).
Ожидаемый результат этапа
- Графики: утилизация каждого порта (время vs packets/sec), heatmap по узлам.
- Карта топологии с горячими точками (highlighted links).
- Список портов, признанных hot spots.
Этап 4: Оптимизация и повторное измерение (45-60 минут)
Действия
-
Применить одну или несколько оптимизаций
- Смена алгоритма маршрутизации (на коммутаторе):
ibdiagnet -r routing -H adaptive(адаптивная маршрутизация). - Уменьшение числа потоков NCCL (изменить
NCCL_NTHREADSилиNCCL_MAX_NCHANNELS). - Pin mapping (привязка процессов к GPU): проверить, что коммуникация идёт через NVLink + InfiniBand оптимально.
- Настройка QoS (приоритетные очереди для all-reduce).
- Смена алгоритма маршрутизации (на коммутаторе):
-
Запустить all-reduce повторно (те же параметры)
mpirun --hostfile hosts.txt -np 64 ./build/all_reduce_perf -b 128M -e 8G -f 2 -n 10 -w 5 -
Повторный сбор perfquery во время нового прогона (как в этапе 2).
Сравнить утилизацию: средняя загрузка портов после оптимизации. -
Документировать изменения и результаты
Записать baseline, целевые значения, фактическое снижение.
Ожидаемый результат этапа
- Новая утилизация сети (средняя) <70%.
- Список применённых оптимизаций с эффектом.
- Сравнительные графики (до/после).
Этап 5: Оформление отчёта (30-60 минут)
Действия
-
Создать Markdown-отчёт с разделами:
- Цель.
- Конфигурация кластера (IB версия, топология).
- Методика сбора.
- Baseline (утилизация, ошибки).
- Hot spots (таблица портов с утилизацией >85% и ошибками).
- Оптимизации и их влияние.
- Итоговая утилизация.
- Рекомендации (аппаратные/программные).
-
Приложить визуализации (heatmap, топология с hot spots, график временного ряда).
-
Добавить лог вывода all_reduce_perf (пропускная способность до/после).
-
Выложить артефакты в Git-репозиторий (папка
network_profiling/).
Ожидаемый результат этапа
- Markdown-документ
network_congestion_report.md. - Папка
figures/с PNG-графиками. - CSV-файлы сырых данных.
5. Критерии приемки (Definition of Done)
- perfquery успешно выполнен на всех портах до, во время и после all-reduce; данные консистентны.
- ibdiagnet построил топологию и CSV-отчёт без ошибок.
- Выявлены не менее 2 горячих точек (порт с утилизацией >85%).
- Зафиксирована baseline утилизация (среднее по времени) >85%.
- После применения хотя бы одной оптимизации утилизация снижена до <70% (подтверждено повторным замером).
- Отчёт содержит таблицу hot spots, графики, описание оптимизаций, рекомендации.
- Все артефакты (CSV, скрипты, отчёт) структурированы и доступны для повторения.
6. Ожидаемый результат
Основной артефакт
network_congestion_report.md— детальный отчёт с метриками, визуализациями, выводами и рекомендациями.- Папка
data/с CSV-файлами perfquery (baseline, loaded, optimized). - Папка
figures/с графиками (heatmap_port_utilization.png, topology_hotspots.png, time_series.png). - Скрипты сбора:
collect_perf.sh,analyze_hotspots.py. - Лог вывода
all_reduce_perfдо и после.
Дополнительные результаты (опционально):
- Пулл-реквест с изменениями конфигурации сети (например, настройки QoS).
- Документация по использованию perfquery и ibdiagnet для команды.
7. Возможные сложности и их решение
| Сложность | Решение |
|---|---|
| Нет физического InfiniBand кластера | Использовать симуляцию на Linux-ВМ с softiwarp и iperf3; сфабриковать данные для perfquery с помощью скрипта. |
| perfquery не даёт доступ ко всем портам | Запускать от root или с правами CAP_NET_RAW; проверить LID порта через ibstat. |
| ibdiagnet выводит огромные файлы | Фильтровать с -s <guid> или использовать grep; анализировать только интересующие порты. |
| All-reduce не запускается на 64 процессах из-за нехватки ресурсов | Уменьшить число GPU (например, 4 узла × 8 GPU = 32); масштабировать цель утилизации пропорционально. |
| Разница в производительности между стэком и симуляцией | Чётко описать в отчёте среду; фокус на методологии, а не абсолютных цифрах. |
| Перегрузка сети приводит к падению all_reduce_perf | Увеличить timeout (NCCL_TIMEOUT=30) или уменьшить размер сообщения. |
8. Бюджет времени (оценка)
| Этап | Время (часы) |
|---|---|
| Этап 1: Подготовка + baseline | 1.0 |
| Этап 2: Сбор данных под нагрузкой | 0.75 |
| Этап 3: Анализ hot spots | 1.5 |
| Этап 4: Оптимизация + повторный замер | 1.0 |
| Этап 5: Отчёт | 0.75 |
| Итого | 4.5 |
Примечание При первом выполнении потребуется дополнительное время на отладку инструментов (≈1 час). Рекомендуется заложить 6 часов с учётом нештатных ситуаций.
9. Связанные вопросы из базы знаний
| Вопрос | Тема |
|---|---|
| 12 | Основные причины падения производительности all-reduce в InfiniBand |
| 31 | Счётчики производительности порта InfiniBand: какие собирать |
| 48 | Построение графа сети с помощью ibdiagnet |
| 63 | Настройка QoS для приоритизации трафика HPC |
| 77 | Разница между адаптивной и статической маршрутизацией |
| 92 | Сбор и интерпретация CRC ошибок на линках InfiniBand |
| 108 | Оптимизация bunched kernel launches в NCCL |
| 124 | Как работает коллективная операция all-reduce в мульти-GPU |
| 141 | Профилирование intra-node vs inter-node коммуникаций |
| 205 | Использование perfquery для мониторинга в реальном времени |
10. Чек-лист самопроверки
- У меня есть доступ к 8 узлам с InfiniBand (или симуляция готова).
- Я могу выполнить
ibstatна каждом узле и убедиться, что все порты активны. -
ibdiagnetустановлен и работает без ошибок. - NCCL-tests скомпилированы и all_reduce_perf запускается на 64 процессах.
- Скрипт сбора perfquery работает и создаёт корректные CSV.
- После сбора я построил визуализации (heatmap, топологию) и нашёл не менее двух горячих точек.
- Я применил хотя бы одну оптимизацию (например, адаптивную маршрутизацию).
- После оптимизации я снова запустил all-reduce и проверил, что утилизация <70%.
- Отчёт содержит все обязательные разделы и приложены артефакты.
- Я могу воспроизвести все шаги в течение 4-5 часов без посторонней помощи.