Инструмент статистики Megascale

Инструмент Megascale Stats можно использовать для анализа производительности межсрезовой связи рабочих нагрузок, охватывающих несколько срезов TPU, которые взаимодействуют через сеть центров обработки данных (DCN).

Все показатели, отображаемые в инструменте Megascale Stats, генерируются для каждого TPU отдельно.

Поддерживаемые платформы

Инструмент Megascale Stats поддерживается только на TPU.

Терминология, связанная с коллективами

Инструмент отображает метрики, связанные с коммуникацией между срезами TPU, которые включают следующие операции:

• send : прерывает работу хоста для запуска прямого доступа к памяти (DMA) и предоставляет хосту заполненный буфер для начала передачи данных.
• send-done : сигнализирует хосту о завершении передачи данных.
• recv : Предоставляет хосту пустой буфер для заполнения переданными данными.
• recv-done : Сигнализирует хосту о том, что данные получены.

Коллективный запрос инициируется операцией send и завершается соответствующей операцией recv-done . Фактическая отправка данных происходит после завершения операции send. Операция send-done выполняется после отправки данных. Аналогично, данные принимаются после завершения операции recv . Операция recv-done выполняется после получения данных.

Компоненты интерфейса

Инструмент отображает таблицу со следующими столбцами, по одной строке на каждую профилированную коллективную операцию:

• Коллективное название DCN: Присвоено XLA.
• Имя операции приема (Recv op name): Имя операции recv-done TPU. Это упрощает поиск соответствующих коллективных операций TPU в Trace Viewer.
• Имя операции отправки: Имя операции send TPU.
• Резервное время: определяется как независимое от сети время, отведенное коллективу для передачи данных. Это мера времени, доступного коллективу для отправки и получения данных, за исключением операций send , send-done , recv или recv-done . Увеличение резервного времени снижает вероятность остановки TPU для коллектива. Например, рассмотрим следующую временную шкалу:

Slack time is calculated in this example as:

Slack time = t<sub>1</sub> + t<sub>2</sub> + t<sub>3</sub>

• Наблюдаемая длительность: наблюдаемая длительность для каждого коллектива. Она вычисляется как интервал между началом операции send и окончанием соответствующей операции recv-done , включая время, затраченное на отправку и получение данных. Например, для следующей временной шкалы:

Observed duration is calculated as:

Observed duration = t<sub>send</sub> + t<sub>1</sub> + t<sub>send-done</sub> + t<sub>2</sub> + t<sub>recv</sub> + t<sub>3</sub> + t<sub>recv-done</sub>

• Длительность простоя: время, в течение которого коллектив останавливает TPU. Это общая продолжительность времени, затрачиваемого коллективом на выполнение операций send , send-done , recv и recv-done , без учёта времени, затраченного на передачу данных. Например, рассмотрим следующую временную шкалу:

Stall duration is calculated in this example as:

Stall duration = t<sub>send</sub> + t<sub>send-done</sub> + t<sub>recv</sub> + t<sub>recv-done</sub>

• Вхождения: общее количество инициаций и завершений коллективного запроса в течение периода действия профиля. Операция send и соответствующая ей операция recv-done должны быть выполнены в течение периода действия профиля, чтобы быть включенными в эту метрику.
• Суммарное общее время простоя: общее время, в течение которого группа участников останавливает TPU в течение продолжительности профиля. Суммарное общее время простоя рассчитывается как:
  • Суммарное общее зависание = продолжительность зависания * количество случаев
• Размер передаваемых данных: объем данных, передаваемых по сети для коллектива, рассчитываемый на основе формы операции XLA.
• Требуемая пропускная способность: пропускная способность, необходимая для передачи данных в рамках предоставленного резерва. Эту метрику можно использовать для определения количества коллективов, конкурирующих за пропускную способность сети в течение действия профиля. Требуемая пропускная способность рассчитывается следующим образом:
  • Требуемая пропускная способность = объем переданных данных / резервное время

Анализ данных инструмента Megascale Stats

Для анализа данных, представленных в инструменте:

1. Сортировать таблицу по Aggregated Total Stall в порядке убывания.
2. Определите название коллективного имени DCN с наибольшим Aggregated Total Stall . Значительно более высокое значение по сравнению с другими может указывать на наличие узкого места.
3. Умножьте Required Bandwidth коллектива DCN на количество ядер (например, 8 на хост TPU v4). Если это значение превышает максимальную пропускную способность сети TPU, это может указывать на перегрузку сети. Попробуйте изменить механизм шардинга , чтобы уменьшить требуемую пропускную способность.
4. Создайте дамп HLO для проверки проблем компиляции. Разделение операций send и recv-done может позволить запланировать больше перекрывающихся операций HLO и сократить время простоя TPU.
5. Проверьте длительность операций recv-done в Trace Viewer для коллектива с максимальным суммарным временем простоя. Большая длительность передачи может указывать на узкое место в полосе пропускания, поскольку операции recv-done обычно блокируются в сети.
6. Если длительность операций recv-done не слишком велика по сравнению с резервным временем, это может указывать на проблему с оборудованием.