slow query log
Тема дорожной карты · PostgreSQL
Журнал медленных запросов PostgreSQL управляется параметром log_min_duration_statement в postgresql.conf, который заставляет базу данных фиксировать в логе любой запрос, выполняющийся дольше указанного числа миллисекунд, делая его незаменимым инструментом настройки производительности и мониторинга. Значение log_min_duration_statement = 1000 записывает все запросы дольше одной секунды, тогда как log_min_duration_statement = 0 фиксирует каждый оператор — это полезно для отладки, но слишком многословно для продуктивного администрирования баз данных. Вывод лога включает текст запроса, продолжительность выполнения и (при настроенном log_line_prefix) имя базы данных, пользователя, адрес клиента и идентификатор процесса, предоставляя полный контекст для расследования медленных запросов в PostgreSQL. Расширение pg_stat_statements дополняет журнал медленных запросов, агрегируя статистику по всем выполнениям нормализованных шаблонов запросов и давая долгосрочное представление о суммарном времени выполнения, а не об отдельных медленных случаях. Обработка журнала медленных запросов PostgreSQL через pgBadger создаёт структурированные HTML-отчёты, ранжирующие запросы по суммарному и среднему времени выполнения, что обеспечивает систематическую настройку производительности и администрирование баз данных при больших объёмах запросов.
Как это работает
slow query log строится на 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%) — пока юзер пожалуется, данные уже были.
Типичные ошибки
Ловушки slow query log: pg_stat_statements не загружен (нельзя ответить "что медленно?" без него); высокий cache-hit интерпретируется как "всё ок" (может быть 99%, пока один запрос трэшит кеш — смотрите ещё I/O); игнор idle in transaction соединений (тихий производитель bloat); нет алертов на тренд использования диска (узнаёте о disk-full в 3:00). Мониторьте тренды, не только снимки.