Наблюдаемость: карта pg_stat_*

Представления pg_stat_* делятся на две природы, и смешать их - самая частая ошибка при диагностике.

• Мгновенный снимок - что происходит прямо сейчас. pg_stat_activity, pg_locks, pg_stat_replication, pg_stat_progress_vacuum. Читаешь - видишь текущее состояние сервера в этот момент.
• Накопленные счётчики - сумма с момента последнего сброса статистики. pg_stat_user_tables, pg_statio_user_tables, pg_stat_database, pg_stat_statements. Число само по себе мало о чём говорит.

Главное следствие: по накопленным счётчикам нельзя сказать «сейчас плохо». Можно сказать только «между двумя замерами выросло вот это». Смысл накопленного счётчика - в дельте за интервал, а не в абсолютном значении. Снял замер, подождал, снял второй, вычел - вот это и есть нагрузка за период.

Первый экран при «база тормозит». Строка на каждое соединение: состояние, текущий запрос, время начала транзакции, чего backend ждёт.

SELECT pid, state, wait_event_type, wait_event,

       now() - xact_start AS xact_age, left(query, 60) AS q

FROM pg_stat_activity

WHERE state <> 'idle'

ORDER BY xact_age DESC NULLS LAST;

Состояния, которые читаешь сразу:

• active - backend прямо сейчас выполняет запрос;
• idle - простаивает между запросами, безвреден;
• idle in transaction - открыл транзакцию и ничего не делает. Вот это тревога: такой backend держит горизонт и мешает vacuum, не выполняя никакой полезной работы. Большой xact_age у такой строки
  • прямой кандидат на причину растущего bloat.

pg_stat_user_tables отвечает на два повседневных вопроса. Первый - нужен ли таблице vacuum: n_live_tup против n_dead_tup и когда приходил last_autovacuum. Второй - читается ли таблица сканом или индексом: seq_scan против idx_scan.

SELECT relname, n_live_tup, n_dead_tup,

       seq_scan, idx_scan, last_autovacuum

FROM pg_stat_user_tables

ORDER BY n_dead_tup DESC;

Большой n_dead_tup при старом last_autovacuum - мусор копится, а автоочистка не успевает или заблокирована горизонтом. Большой seq_scan на большой таблице, по которой ожидался индекс, - сигнал, что индекс не берётся или его нет.

Рядом pg_statio_user_tables про кеш: heap_blks_hit (нашли в буфере) против heap_blks_read (читали с диска). Низкая доля попаданий на горячей таблице - либо мало shared_buffers, либо таблица слишком велика для кеша.

Это расширение - основной инструмент поиска медленного SQL. Оно агрегирует выполнение по нормализованному тексту запроса: WHERE id = 1 и WHERE id = 2 схлопываются в один WHERE id = $1. Поэтому одно тяжёлое место видно как одна строка с суммой по всем своим вызовам - в отличие от лога, где это тысячи отдельных записей.

SELECT queryid, calls, round(total_exec_time) AS total_ms,

       round(mean_exec_time, 1) AS mean_ms, left(query, 70) AS q

FROM pg_stat_statements

ORDER BY total_exec_time DESC

LIMIT 10;

Соблазн - искать «самый медленный запрос» по mean_exec_time. Это уводит не туда. Запрос на 10 секунд, выполненный раз в сутки, съедает меньше ресурса, чем запрос на 2 миллисекунды, выполненный миллион раз.

Поэтому виновника нагрузки ищут по total_exec_time - суммарному времени по всем вызовам. Именно он показывает, на что сервер реально тратит время. mean полезен потом, когда виновник найден и надо понять, дорог он за вызов или берёт частотой.

pg_stat_statements говорит «какой класс запросов жрёт время», но теряет конкретные значения параметров. Дополняет его log_min_duration_statement - порог в миллисекундах, выше которого каждый медленный запрос пишется в лог сервера целиком, с реальными параметрами.

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

Расширение auto_explain идёт ещё дальше: пишет в лог сам план медленного запроса, без ручного воспроизведения. Полезно, когда запрос тормозит только на проде и только иногда.

Сила наблюдаемости - не в отдельном представлении, а в их сцепке. Типовая диагностика «база встала» идёт по цепочке:

1. pg_stat_activity - кто активен, кто висит в idle in transaction, чего ждут (wait_event);
2. если видны блокировки в wait_event - pg_locks плюс pg_stat_activity, чтобы найти blocker по pid;
3. если виновата нагрузка запросами - pg_stat_statements топ по total_exec_time;
4. если растёт мусор - pg_stat_user_tables по n_dead_tup и last_autovacuum, и назад к шагу 1 искать, кто держит горизонт.

Каждое представление отвечает на свой вопрос; диагноз рождается из их пересечения. Эту карту мы используем в капстоуне, когда будем расследовать деградацию по всем фронтам сразу. Полная справка - в pg-stat-map.