Как читать PSI в Linux: проверить давление на CPU, память и диск

Высокая загрузка CPU не всегда означает, что серверу плохо, а почти занятая память не всегда требует увеличения VPS. Полезнее знать, сколько времени задачи не могли продвигаться из-за нехватки процессора, памяти или ввода-вывода. Для этого ядро Linux предоставляет Pressure Stall Information — PSI.

Инструкция относится к Linux с включённым PSI и интерфейсом procfs. Команды сверены с документацией ядра 26 сентября 2026 года и только читают данные. В использованном изолированном окружении файлы PSI не были смонтированы, поэтому выполнение подтвердило ожидаемую ошибку отсутствия интерфейса, но не дало числового примера с реального сервера.

Если каталог существует, в нём обычно доступны файлы для процессора, памяти и ввода-вывода. Отсутствие каталога означает, что ядро, его конфигурация или контейнерное окружение не предоставляют PSI. Не создавайте эти файлы вручную: это виртуальный интерфейс ядра.

Чтение почти не создаёт нагрузки. Оно показывает текущие скользящие средние и накопленное время ожидания с момента загрузки или создания соответствующей группы. Значения нужно сопоставлять с интервалом, мониторингом и пользовательскими задержками.

Строка some означает, что хотя бы часть задач задерживалась из-за ресурса. Строка full означает более тяжёлое состояние: одновременно не могла выполнять полезную работу вся группа нетривиальных задач. Для CPU обычно доступна только some, потому что при наличии исполняемой задачи процессор всё равно занят полезной работой.

Значение 5,00 в среднем не означает пять секунд ожидания и не равно загрузке CPU. Это доля времени в процентах за окно. Для оценки накопленного поля берут две точки и делят прирост total на длительность интервала в микросекундах.

Для ручной проверки сохраните вывод, подождите согласованный короткий интервал под наблюдением и снимите его снова. Не создавайте искусственную нагрузку на рабочем сервере. Сравните прирост total с графиками ответа сайта и другими метриками.

Если мониторинг собирает PSI регулярно, ручной расчёт не нужен. Важно сохранить сырые поля, интервал и область измерения. В контейнере показатели могут относиться к cgroup, хосту или быть скрыты — это зависит от конфигурации; границу нужно проверить до выводов.

Короткое давление во время резервного копирования и постоянное давление во время оформления заказов имеют разный риск. Порог выбирают из базовой линии и допустимой задержки конкретного сервиса. Сначала отмечают корреляцию с временем ответа, ошибками и очередями, затем задают предупреждение и критический уровень.

PSI не заменяет обычные метрики. Для CPU нужны использование и очередь, для памяти — доступный объём, swap и владельцы, для диска — задержка и пропускная способность. PSI добавляет ответ на вопрос, мешал ли дефицит ресурса задачам выполнять работу.

Сначала сохраните интервал и контекст, затем меняйте одну причину за раз. PSI особенно полезен не как красный индикатор, а как способ отделить занятость ресурса от реального ожидания и проверить, помогло ли изменение системе выполнять работу.

High CPU usage does not always mean the server is in trouble, and nearly full memory does not always require increasing VPS resources. It is more useful to know how long tasks could not progress due to lack of CPU, memory, or I/O. For this, the Linux kernel provides Pressure Stall Information, or PSI.

This guide applies to Linux with PSI enabled and the procfs interface. Commands are verified against kernel documentation dated September 26, 2026, and only read data. In the isolated environment used, PSI files were not mounted, so execution confirmed the expected error of a missing interface but did not provide a numerical example from a real server.

If the directory exists, files for CPU, memory, and I/O are usually available. The absence of the directory means the kernel, its configuration, or the container environment does not provide PSI. Do not create these files manually: this is a virtual kernel interface.

Reading imposes almost no load. It displays current moving averages and accumulated wait time since loading or the creation of the corresponding group. These values must be correlated with the interval, monitoring data, and user latency.

The some line indicates that at least part of the tasks were delayed due to resource pressure. The full line indicates a more severe state: the entire group of non-trivial tasks was unable to perform useful work simultaneously. For CPU, only the some line is typically available because if an executable task exists, the processor remains busy with useful work.

An average value of 5.00 does not mean five seconds of wait time, nor does it equal CPU utilization. It represents the percentage of time within the window. To evaluate the accumulated field, take two data points and divide the increase in total by the interval duration in microseconds.

For manual verification, save the output, wait for a consistent short interval under observation, and capture it again. Do not create artificial load on a production server. Compare the increase in total with the website response graphs and other metrics.

If monitoring collects PSI data regularly, manual calculation is unnecessary. It is important to preserve the raw fields, interval, and measurement scope. In containers, metrics may relate to cgroups, the host, or be hidden; this depends on the configuration, so the boundary must be verified before drawing conclusions.

Brief pressure during backup and sustained pressure during order placement carry different risks. The threshold is selected based on the baseline and the acceptable latency of the specific service. First, correlate with response time, errors, and queues, then set warning and critical levels.

PSI does not replace standard metrics. For CPU, you need utilization and the run queue; for memory, available volume, swap, and owners; for disk, latency and throughput. PSI adds the answer to whether resource scarcity prevented tasks from doing work.

First, save the interval and context, then change one cause at a time. PSI is especially useful not as a red alert, but as a way to distinguish resource saturation from actual waiting and to verify whether a change helped the system perform work.