Метрики VMSTAT

Ранжирование метрик vmstat для PostgreSQL — это не строгая наука, так как влияние зависит от типа нагрузки (OLTP, OLAP, смешанная) и конкретных проблем. Однако можно выделить приоритет на основе критичности для типичной работы СУБД.

Общие приоритеты по метрикам vmstat для оценки влияния на производительность СУБД

Группа 1: Критически важные (прямые признаки серьезных проблем)

1. si (swap in) и so (swap out)

• Влияние: Абсолютный приоритет №1. Даже незначительный свопинг (si > 0) убивает производительность PostgreSQL, так как движок рассчитывает на резидентность данных в оперативной памяти. Свопинг вызывает лавинообразное увеличение задержек ввода-вывода (I/O wait).
• Что смотреть: Любое ненулевое значение, особенно в si, — это красный флаг. so может быть незначительным при старте, но не во время работы.

2. us (user time), sy (system time) и wa (I/O wait time)

• Влияние: Эти три метрики в сумме показывают утилизацию CPU и ее причину.
• wa (I/O wait): Самый критичный из этой тройки. Высокий wa (> 20-30%) означает, что процессы (в т.ч. PostgreSQL) простаивают в ожидании операций с диском. Это прямой признак проблем с хранилищем (медленный диск, нехватка RAM → кэш-промахи, неправильная конфигурация). Низкая производительность гарантирована.
• us + sy: Высокие значения (> 70-80% в сумме) указывают на CPU-нагруженную работу (вычисления, агрегации, обработка данных в памяти). Это может быть как нормой для аналитических запросов, так и признаком неоптимальных планов выполнения (отсутствие индексов, плохие запросы).

3. free / buff / cache (в современных vmstat часто free + inact + active)

1. Влияние: Косвенный, но очень важный показатель. PostgreSQL активно использует cache (через page cache ОС) и свои собственные буферы (shared_buffers). Малое значение free памяти при активном использовании cache — это норма. Но если free стабильно стремится к нулю, а si/so растут, это предвестник свопинга. Важно следить за трендом, а не за абсолютным значением.

Группа 2: Очень важные (прямое влияние на отзывчивость)

4. b (blocked processes)

• Влияние: Показывает процессы, заблокированные в ожидании ресурсов (чаще всего ввода-вывода). Если b постоянно > 1-2, это явный признак проблем с подсистемой I/O или конкуренции за блокировки внутри СУБД (что vmstat уже не покажет, нужно смотреть в pg_locks).

5. bi (blocks in) и bo (blocks out)

• Влияние: Показывают интенсивность физического чтения с дисков (bi) и записи на диски (bo).
• bi: Высокие значения при OLTP-нагрузке — признак того, что данные не помещаются в оперативную память (неэффективный кэш).
• bo: Постоянно высокие значения могут быть признаком интенсивной записи WAL, работы контрольных точек (checkpoint), фоновой записи «грязных» страниц. Если bo высокий одновременно с высоким wa, система упирается в производительность хранилища.

Группа 3: Важные для понимания общей картины

6. r (runnable processes)

• Влияние: Показывает количество процессов, готовых к выполнению. Если r постоянно превышает количество ядер CPU в 2 и более раза, это признак конкуренции за процессорное время (CPU saturation). Сервер не успевает обрабатывать нагрузку, запросы начинают ждать в очередях.

7. cs (context switches)

• Влияние: Очень высокие значения (сотни тысяч в секунду) могут указывать на проблему с «эффектом ореола» (too many backends), активную работу планировщика и излишние переключения между процессами, что съедает CPU.

8. in (interrupts)

• Влияние: Резкий рост может быть связан с сетевым оборудованием или дисковыми прерываниями. Обычно менее информативен для диагностики СУБД напрямую, но может указывать на проблемы с железом/гипервизором.

Итоговая таблица приоритетности для быстрой диагностики

Практический совет: Всегда смотрите на метрики в комплексе.

• Классическая проблема «тормозит всё»: free мало, si > 0, wa высокий, b > 0. Вывод: Нехватка оперативной памяти → свопинг → лавина I/O wait.
• Проблема с дисковой подсистемой: wa высокий, b высокий, возможно повышенные bo (при checkpoint), но si = 0. Вывод: Хранилище не справляется с нагрузкой записи.
• Проблема с CPU/запросами: us высокий, r высокий, wa низкий, si = 0. Вывод: Нужно оптимизировать запросы, добавлять индексы, возможно, масштабировать CPU.