pg_stat_activity
Тема дорожной карты · PostgreSQL
pg_stat_activity — системное представление PostgreSQL, предоставляющее по одной строке на каждый серверный процесс с отображением текущего состояния соединения, текста активного запроса, типа события ожидания, времени начала запроса и адреса клиента; это незаменимый инструмент мониторинга базы данных в режиме реального времени. Администраторы баз данных обращаются к pg_stat_activity для выявления долго выполняющихся запросов, обнаружения конкуренции за блокировки, мониторинга соединений «простаивающих в транзакции», удерживающих блокировки, и диагностики проблем производительности в работающей системе PostgreSQL. Совместное использование pg_stat_activity и pg_locks позволяет операторам восстанавливать полные цепочки зависимостей блокировок и завершать блокирующие запросы с помощью pg_terminate_backend() или pg_cancel_backend(). Параметр track_activity_query_size в postgresql.conf управляет числом символов текста запроса, хранимых в каждой строке pg_stat_activity, что важно при работе с очень длинными запросами. Регулярный мониторинг pg_stat_activity — фундаментальная практика настройки производительности и администрирования баз данных PostgreSQL, помогающая поддерживать работоспособность и отзывчивость системы.
Как это работает
pg_stat_activity строится на pg_stat_statements (топ-запросы по total/avg, calls), pg_stat_user_tables (sequential vs index scans, dead tuples), pg_stat_activity (текущие соединения, запросы, lock waits), pg_stat_replication (lag реплик). Внешние: prometheus-postgres-exporter, pganalyze (коммерческий), pgwatch2. Расширения: pg_stat_kcache (per-query I/O), pg_buffercache (содержимое кеша), auto_explain (логирование плана медленных запросов).
Когда применять
Включите pg_stat_statements + auto_explain с первого дня — стоят почти ничего, находят медленные запросы, о которых вы не знали. Добавьте prometheus-postgres-exporter и дашборды: connections, lock waits, replication lag, cache hit ratio, dead tuples, возраст транзакций. Alerts на горячие условия (lock wait > 30s, replication lag > 60s, cache hit < 95%) — пока юзер пожалуется, данные уже были.
Типичные ошибки
Ловушки pg_stat_activity: pg_stat_statements не загружен (нельзя ответить "что медленно?" без него); высокий cache-hit интерпретируется как "всё ок" (может быть 99%, пока один запрос трэшит кеш — смотрите ещё I/O); игнор idle in transaction соединений (тихий производитель bloat); нет алертов на тренд использования диска (узнаёте о disk-full в 3:00). Мониторьте тренды, не только снимки.