GPU Memory Residency становится важным тогда, когда device memory, host pinned memory, managed memory, prefetch и advice перестают быть фоновой деталью платформы и начинают определять доступную производительность. В такой ситуации настройка превращается не в поиск единственного нужного флага, а в управляемую проверку гипотез. Нужно знать, какой путь проходит запрос, где он получает ресурс, где ждёт и каким счётчиком это видно. Иначе даже правильный параметр прочитают как ошибку, потому что фон был слишком грязным.
Что именно нужно измерять перед изменением параметров
Первый шаг состоит в описании рабочего контура. Для GPU Memory Residency это почти всегда связка приложения, ядра, драйвера, firmware и конкретного физического пути данных. Если в документе отсутствует точный узел NUMA, слот, ядро обработчика или регион памяти, диагностика быстро скатывается к спорам. Измеряться должны latency, throughput, число повторных операций, ошибки и сам переход между состояниями.
Baseline должен быть достаточно подробным, чтобы после изменения можно было ответить на простой вопрос: что именно улучшилось и ценой чего. Полезно хранить sysinfo, конфигурацию, команду теста, версию драйвера и несколько прогонов. Для GPU Memory Residency сравнение baselines между узлами часто обнаруживает проблему раньше, чем сложный анализ одного узла.
Какие сигналы заранее показывают неудачную настройку
О неудачной настройке часто говорит не падение среднего, а изменение формы распределения. Задержка становится рваной, редкие запросы приходят пачками, повторные операции начинают расти при том же входном потоке. Для GPU Memory Residency важно смотреть и на смежные счётчики: прерывания, миграции, троттлинг, заполнение буферов и системные журналы. Одиночная метрика почти всегда врёт.
Другой ранний признак связан с восстановлением. Если после встряски системы GPU Memory Residency возвращается в работу с другой скоростью, конфигурация зависит от того, кто первым успел захватить ресурс. Это особенно неприятно в серверах с автоматическим раскатом, где одинаковая нагрузка уезжает на узлы с одинаковым на бумаге железом. На практике одинаковость нужно доказывать измерениями.
Практическая последовательность безопасного изменения параметров
Безопасное изменение строится узкими шагами. Сначала подтверждается доступность механизма, затем фиксируется привязка к топологии, потом выбирается размер рабочей порции и только потом трогается агрессивная политика. Каждый шаг должен иметь быстрый откат. Для GPU Memory Residency хороший откат значит не только возврат значения, но и подтверждение, что счётчики вернулись к baseline.
Шаги не должны быть слишком частыми. Если после каждого изменения тест занимает сорок минут, инженер начинает экономить на повторах и ошибается чаще. Лучше иметь короткий smoke набор и два длинных подтверждающих запуска. Smoke показывает грубые ошибки, а длинный запуск отвечает на вопрос о стабильности.
Команды и конфигурации, которые снимают неопределённость
Ниже приведён минимальный рабочий набор команд. Его задача состоит в том, чтобы быстро снять фактическое состояние и не опираться на предположения:
$ nvidia-smi
$ nvidia-smi --query-compute-apps=pid,used_memory --format=csv
$ nvidia-smi --query-gpu=memory.total,memory.used,utilization.gpu --format=csv -l 1
$ nsys profile --stats=true ./gpu_app
$ nvidia-smi topo -m
$ compute-sanitizer ./gpu_app 2>/dev/null || true
$ nvidia-smi -q -d MEMORY 2>/dev/null | head -40
Вывод команд стоит архивировать вместе с нагрузочным профилем. Если позже появится иной результат, сравнение должно быть похоже на сверку приборов, а не на угадывание. Для GPU Memory Residency особенно важно снимать состояние до и после изменения, потому что побочный эффект часто виден только в разнице.
Типичные ошибки когда оптимизация делает систему медленнее
Причины обратного эффекта обычно знакомы, но под давлением сроков их забывают:
- включить managed memory и думать, что миграция страниц бесплатна
- держать редко используемый тензор resident и вытеснять рабочий набор
- не учитывать oversubscription и путать его с предсказуемым residency
- читать utilization.gpu как прямой показатель насыщения памяти
Ещё одна классическая ошибка заключается в неправильной экономии. Инженер отключает удобный защитный механизм, чтобы получить цифру повыше, а через месяц эта цифра оборачивается отладкой под нагрузкой. Для GPU Memory Residency безопасность, предсказуемость и способность к восстановлению должны оцениваться вместе с пропускной способностью.
Контрольный список перед выкладкой в продуктивную среду
Перед продуктивной выкладкой используйте компактный список:
- разделить данные на hot, warm и cold ещё до выбора политики размещения;
- при managed memory использовать prefetch в фазу, где есть запас по шине;
- проверять page fault rate и время map on host после каждой оптимизации;
- оставлять свободный запас памяти под временные буферы библиотеки.
При работе с GPU Memory Residency решает не столько название параметра, сколько повторяемость. Если один и тот же тест на одной системе даёт стабильный результат, а на соседней гуляет, узкое место лежит глубже приложения. Обычно это топология, привязка прерываний, прошивка или неочевидная разница в состоянии памяти.
Полезно смотреть на систему глазами обслуживающего инженера. Через полгода никто не будет помнить, почему значение выбрали именно таким. Короткая заметка рядом с конфигурацией, где указаны baseline, нагрузка и критерий отката, экономит больше времени, чем дополнительный рост средней скорости.
Для GPU Memory Residency опасен эффект почти исправной системы. Всё работает, графики гладкие, но раз в несколько дней появляется короткое окно деградации. Такие случаи ловятся длинным наблюдением и корреляцией с обновлениями, миграциями, температурой и фоновыми задачами. Быстрый тест эту картину не покажет никогда.
Хороший признак зрелой настройки состоит в том, что после изменения становится понятнее, а не быстрее любой ценой. Когда рычаг действительно нужный, повышается не только скорость, но и предсказуемость. Когда рычаг случайный, система радует один день, а потом возвращает всё с процентами в виде сложной диагностики.
Если GPU Memory Residency конфликтует с политикой безопасности, экономией энергии или ограничением виртуализации, это не всегда блокер. Часто проблема решается смещением нагрузки на другой ресурс, изменением размера буфера или разделением критичного и фонового пути. Главное состоит в том, чтобы компромисс был записан и измерен, а не выбран молча.
Заключительный критерий звучит просто: система должна вести себя одинаково после холодного старта, после тёплого прогона и после восстановления из ошибки. Если GPU Memory Residency прошёл все три состояния без сюрпризов, настройку можно считать готовой к эксплуатации.