Pull to refresh

Comments 8

Почти все очевидные грабли собрали, удачно выступили :) Единственно что смущает - падучесть процессов. Распределенный алгоритм в вашей классификации - это не про отказы узлов. Распределенный алгоритм работает на сете узлов - это всё. А то что про таймауты и восстановление после отказа - это Fault Tolerance, для которого вы кстати и делаете свой снапшот время от времени.

Кстати хороший вопрос, а как вы предлагаете делать тестирование всех маршрутов в IB, если роутинг не прозрачен для пользователя? Т.е. вы не знаете какой маршрут будет выбран на втором уровне кор свичей?

В общем случае действительно не знаем. На практике тестирование перебором всех сетевых пар и последуюший allreduce для всех узлов с высокой вероятностью ловит ошибки.

Ну банальный перебор ничего не гарантирует в принципе. Максимум - проверка линков на уровне лифа. А любой коллектив внутри себя имеет свой алгоритм, который тоже может не загрузить линки как вы предполагаете.

Это не "фейковая" утилизация. То, что вы смотрите через nvidia-smi это утилизация пайплайна. Она будет 100% даже если ядро не делает ничего кроме yield, как вы заметили.

Для более полной картины есть средства мониторинга DCGM https://developer.nvidia.com/dcgm. Посмотрите на метрики здесь https://docs.nvidia.com/datacenter/dcgm/latest/dcgm-user-guide/feature-overview.html#profiling. То, nvidia-smi показывает как утилизацию, наиболее близко к Graphics Engine Activity метрике. Обратите внимание на другие метрики и их значение. Да, они не работают с пользовательскими картами GTX/RTX серии. Нужны карты семейства Quadro/Tesla/Titan.

Конечно вы правы, мы уже смотрим на эти счетчики. Проблема в том что когда мы начинали собирать наши кластера DCGM еще не выложили в opensource. И мы наивно доверяли nvidia-smi. хотя в nvml все эти метрики уже были. Эта статья как ретроспектива граблей которые мы насобирали, в надежде на то что это поможет остальным совершить меньше ошибок.

Ну, по правде говоря, как раз модуль, ответственный за profiling metrics, как раз в open-source и не выложен. В nvml их к сожалению тоже нет. Все, что есть в NVML, вы видите в выводе nvidia-smi, по сути просто cli обертка над nvml api.

спасибо за DCGM, не знал, может есть еще под рукой что почитать или посмотреть про мониторинг и диагностику обучения/загрузки карт?

Если брать Нвидийные карточки, то большинство решений о которых есть публикации (FB/Meta, MS) делают решения на основе DCGM так или иначе. Есть несколько опенсорсных попыток сделать что-то вроде top/htop (кажется nvtop назывался), но они все, по сути, обертки над nvml со всеми вытекающими издержками на получение метрик. DCGM использует непубличные интерфейсы для возможности уменьшить издержки на системные вызовы. Так получилось, что это физически те же механизмы, что использует nsight, так что одновременный профайлинг и сбор метрик не работает. У Меты есть презентации как они на своих кластерах решают эту проблему (у DCGM есть механизм временной остановки сбора метрик, которые влияют на nsight).

Sign up to leave a comment.