Вопрос или проблема
Я занимаюсь устранением проблемы на высокопроизводительном сервере, который используется для глубокого обучения, где процессы периодически останавливаются во время больших рабочих нагрузок. Спецификации сервера и соответствующие детали следующие:
Конфигурация:
- ЦП: 2 сокета, 32 ядра на сокет, 2 потока на ядро (64 логических ЦП на узел NUMA, всего 128 логических ЦП).
- Память: ~500 ГБ ОЗУ, разделенная между двумя узлами NUMA (каждый узел имеет ~250 ГБ).
- Дисковое пространство: 12 ТБ SSD
- Файл подкачки: 8 ГБ (часто полностью используется, не только во время остановок).
- Графические процессоры: 4 Nvidia A100 с 80 ГБ каждый
- ОС: Ubuntu 22
- Мы вручную используем taskset и файл Excel для предотвращения совместного использования ЦП между процессами
- Для применения моделей мы используем pytorch с драйверами cuda для GPU
Проблема:
- Во время обучения, проверки или применения крупных моделей машинного обучения на изображениях размером до гигапикселя (>4 ГБ), процессы иногда останавливаются, то есть прогресс останавливается
- Когда происходит остановка, затронутые ЦП в htop показывают 100% использование и становятся красными.
- Единственное решение, которое мы нашли до этого момента, это убить один из затронутых процессов. После этого несбитые процессы возвращаются к нормальной обработке и продолжают, как будто ничего не произошло.
- Мне не удается воспроизвести проблему, она просто возникает иногда, по-видимому, когда сервер находится под большой нагрузкой. Однако я не могу определить явное узкое место, вызывающее проблему
Что я наблюдал:
- Память NUMA: используемый узел NUMA имеет достаточно свободной памяти (например, 40+ ГБ, как показано с помощью numactl –hardware). Даже если нет, остановка происходит не всегда. Мне удавалось даже увеличить нагрузку на уже перегруженный узел NUMA, и все прошло хорошо.
- I/O: используя iostat, я наблюдал всплески до ~110 МБ/с чтение и ~5 МБ/с запись во время рабочей нагрузки.
- Файл подкачки полностью используется (~8 ГБ). Однако файл подкачки часто полностью используется, даже когда есть ~150 ГБ свободной памяти, и тогда проблем нет
- Набор данных находится на SSD
- Красные полосы в htop: как показано на прикрепленном скриншоте htop, должно быть достаточно ОЗУ и ЦП, как я думаю. Также есть процесс, который все еще работает, как видно на ЦП 32-55. Примечательно, что он работает на другом узле NUMA (Node_0 =~250 ГБ ОЗУ с CPU0-31+64-95, Node_1=~250 ГБ ОЗУ со всеми остальными ЦП).
- Поскольку данная проблема наблюдалась с разными скриптами, и не имеет значения, какой скрипт мы убиваем для решения остановки, я бы предположил, что это не вызвано ошибкой в конкретном скрипте.
Я предполагаю, что проблема либо на стороне ЦП, либо на стороне ОЗУ. Однако и в том, и в другом случае у меня были случаи, когда явно достаточно ресурсов, но остановка все равно происходила.
Так что мне нужны дополнительные ресурсы, которые я могу мониторить, чтобы выявить первопричину проблемы остановки. Кроме того, какой-то способ воспроизвести такое поведение помог бы мне понять проблему.
Шаги, которые я предпринял:
- Как предложил @Halfgaar, я установил htop для отображения подробной информации о полосах ЦП
- Что касается файла подкачки, мне нужно связаться с моими руководителями, является ли отключение файла подкачки вариантом.
Ответ или решение
Диагностика проблем с процессами, которые «зависают» на высокопроизводительном сервере, требует внимательного и систематического подхода для выявления и устранения возможных узких мест и проблем. Рассмотрим различные аспекты проблемы и предложим возможные решения.
Теория
Высокопроизводительные серверы, особенно используемые для глубокого обучения и обработки больших объемов данных, должны справляться с огромными нагрузками на процессоры, память, дисковую подсистему и графические процессоры. В первую очередь, необходимо понимать, что зависание процессов может быть связано с несколькими факторами:
-
Использование ЦПУ: Утечки памяти, несвоевременные запросы I/O, плохая оптимизация многопоточности могут привести к 100% использованию процессоров.
-
Управление памятью и NUMA: Неоптимальное распределение ресурсов между NUMA-узлами может приводить к задержкам и конкурсированию ресурсов.
-
Дисковая подсистема и I/O операции: Высокие нагрузки на I/O при работе с большими данными могут приводить к задержкам в данных, особенно если есть необходимость частого обмена данными между диском и памятью.
-
Использование графических процессоров и CUDA: Срабатывание ядра CUDA при непредсказуемых обстоятельствах также может влиять на общую производительность системы.
-
Управление swap: Частое обращение к свопу, особенно в условиях, когда доступно много оперативной памяти, может указывать на проблемы в управлении памятью или конфигурации приложений.
Пример
Возьмем случае, когда система в определенных случаях демонстрирует 100% загрузку процессора, приводя к полному зависанию процессов. В подобных условиях, как показано в описании проблемы, использование htop для детальной диагностики процессов позволяет выявить, что загрузка распределяется неравномерно или перекрывает ресурсы NUMA-узлов. В итоге, когда происходит остановка одного из процессов, другие процессы продолжают нормально функционировать, что косвенно указывает на потенциальный конфликт или deadlock в управлении потоками или распределении ресурсов.
Применение
Для разрешения описанных проблем, предлагается реализовать следующие шаги:
-
Оптимизация управления многопоточностью:
- Проверьте вашу конфигурацию taskset, чтобы убедиться, что процессы не занимают одни и те же ядра на разных NUMA узлах.
- Рассмотрите возможность использования cgroups или cpuset для более гибкого управления CPU.
-
Мониторинг и управление NUMA:
- Используйте утилиты, такие как
numastatиnumactl, для детальной диагностики распределения нагрузки по NUMA. - Рассмотрите возможность изменения архитектуры приложения для оптимизации использования памяти и процессоров в пределах каждой NUMA-области.
- Используйте утилиты, такие как
-
Управление ресурсами памяти:
- Попробуйте отключить swap или увеличить его размер в зависимости от наблюдаемых результатов. Проведите анализ, чтобы определить, насколько оптимален текущее использование свопа.
- Проверьте, нет ли утечек памяти в ваших приложениях или зависимостях.
-
Диагностика и оптимизация I/O операций:
- Проанализируйте нагрузку на дисковую подсистему и распределение доступа к файлам. Используйте
iostatи другие инструменты для выявления узких мест и оптимизации. - Обратите внимание на паттерны доступа к данным приложений. Возможно, необходимо оптимизировать операции чтения/записи для снижения времени доступа.
- Проанализируйте нагрузку на дисковую подсистему и распределение доступа к файлам. Используйте
-
Оптимизация работы с GPU и CUDA:
- Убедитесь в том, что используемые версии PyTorch и CUDA совместимы и настроены оптимальным образом для вашей архитектуры.
- Проверьте конфигурацию моделей и их зависимостей на предмет потенциальных проблем с производительностью.
Для дальнейшего углубленного анализа может понадобиться ведение журналов на более низком уровне (например, с помощью strace или perf), чтобы отслеживать системные вызовы и выполнение процессов в реальном времени. Также полезным может быть внедрение диагностики на уровне приложений с использованием библиотек профилирования.
Заключая, ключевым фактором является систематический подход к мониторингу и управлению системными ресурсами с целью выявления и устранения узких мест, поведение которых описывается выше.