В этом материале
PSI показывает время ожидания ресурсов, которое может скрываться за умеренными средними процентами загрузки. Для диагностики задержек сравните pressure на хосте и в cgroup процесса. Эти показатели помогают локализовать stalls CPU, памяти или I/O, но сами по себе не диагностируют GPU.
PSI показывает время ожидания ресурсов, которое может скрываться за умеренными средними процентами загрузки. Для диагностики задержек сравните pressure на хосте и в cgroup процесса. Эти показатели помогают локализовать stalls CPU, памяти или I/O, но сами по себе не диагностируют GPU.
Выберите область наблюдения
На Linux системные показатели доступны в /proc/pressure/cpu, memory и io, если поддержка включена. В cgroup v2 существуют соответствующие файлы pressure для группы. Системная цифра смешивает нагрузки узла, а локальная описывает выбранную иерархию. Сохраните обе области и путь worker: контейнер с небольшой нагрузкой может ожидать ресурс из-за конкуренции с соседями. Снимок dashboard без указания scope не позволяет однозначно объяснить наблюдаемое ожидание.
Различайте some, full и окна
Some означает, что хотя бы часть задач простаивала из-за ресурса; full отражает одновременное ожидание всех не простаивающих задач в соответствующей области. У системного CPU full есть особая семантика: не переносите интерпретацию memory full на него механически. Avg10, avg60 и avg300 показывают разные окна, а total — накопленное время в микросекундах. Проверяйте поддерживаемые поля в версии ядра и сравнивайте изменения, а не только абсолютный total.
Сопоставьте ожидание с рабочим этапом
В учебном случае подготовка данных замедляется, GPU периодически ждёт, а memory some и full растут внутри worker cgroup. Одновременно увеличивается memory.events high. Это повод исследовать reclaim и границу memory.high. Если растёт io pressure без соответствующего memory события, следующий шаг другой. Такие наблюдения описывают условный диагностический сценарий, а не измеренную производительность распределённого пула или конкретного облачного сервера.
| Запись | Назначение |
|---|---|
| Область PSI | Отделить узел от workload |
| Окно avg10/60/300 | Увидеть короткий всплеск и продолжительный эпизод |
| Изменение total | Сравнить одинаковые интервалы |
| Этап приложения | Связать stall с подготовкой или обслуживанием |
Проверяйте гипотезу отдельным изменением
После выбора ресурса изучите его собственные ограничения: CPU quota, memory controller либо путь I/O. Сократите конкурирующую нагрузку на тестовом узле и повторите те же входы. Падение PSI вместе с исчезновением задержки поддерживает гипотезу, но не заменяет понимания механизма. Не назначайте универсальный допустимый процент: чувствительность к stalls зависит от процесса, времени окна и требований конкретной операции. Сравнение разных scope требует отдельной оговорки.
Сохраните временную шкалу
В итоговом артефакте объедините отметки начала нагрузки, stalls, cgroup events и завершения операции. Запишите единицы измерения и интервал сбора. После исправления сравните не только среднюю длительность, но и повторяемость пауз на том же наборе работы. Если задержка сохранилась при спокойном PSI, переходите к сетевым ожиданиям, блокировкам приложения и другим механизмам. Отсутствие pressure не означает, что весь сервис работает правильно; оно лишь сужает область исследования.
Связанные разборы: gpu monitoring scorecard; cpu vs gpu hosting.