Медленный ответ приложения не всегда связан с неудачным запросом. PostgreSQL может ждать освобождения блокировки, читать большой объём данных с диска или выполнять план, рассчитанный по устаревшей статистике. Задача аудита — разделить эти причины и связать наблюдения с конкретной нагрузкой, прежде чем менять настройки.
С чего начинается диагностика
Сначала фиксируют время замедления, затронутые операции и изменения перед инцидентом: выпуск приложения, загрузку данных, рост числа соединений. Показатели сравнивают за сопоставимые периоды. Среднее время ответа может скрывать редкие задержки, поэтому отдельно рассматривают длительные выполнения и частоту вызовов.
Какие данные собрать
Если расширение pg_stat_statements подключено, его статистика позволяет выделить запросы с большим суммарным временем выполнения. Текущую активность и события ожидания смотрят в pg_stat_activity. Планируя аудит PostgreSQL с привлечением специалистов, полезно заранее описать симптомы; аудит PostgreSQL с PGLens также стоит рассматривать через конкретные задачи диагностики, не подменяя измерения предположениями.
- Сохранить примеры медленных запросов и значения параметров, исключив секреты и персональные данные.
- Зафиксировать длительность транзакций и события ожидания в момент замедления.
- Сопоставить нагрузку на процессор и диски с активностью базы за тот же интервал.
Как читать план выполнения
EXPLAIN показывает выбранный план, а EXPLAIN ANALYZE действительно выполняет запрос и добавляет фактические показатели. Для изменяющих данные команд это особенно важно: диагностический запуск может изменить содержимое таблиц. Тяжёлые проверки проводят в согласованных условиях, учитывая нагрузку и побочные эффекты.
В плане сравнивают ожидаемое и фактическое количество строк, число повторений узлов и способы соединения таблиц. Большое расхождение оценок — повод проверить статистику и распределение значений. Последовательное чтение само по себе не ошибка: при выборке значительной части таблицы оно может быть выгоднее индекса. Новый индекс оценивают также по затратам на запись и хранение.
Как искать источник блокировок
Долгое ожидание требует поиска блокирующей сессии, а не только анализа ожидающего запроса. Функция pg_blocking_pids помогает установить эту связь; pg_locks даёт сведения о блокировках. Проверяют возраст транзакции, её состояние и операции приложения. Сессия idle in transaction может удерживать блокировки, хотя сейчас не выполняет запрос. Завершать её без выяснения назначения опасно для текущей работы приложения.
Итоги: проверять изменения на сопоставимой нагрузке
Результат аудита — перечень причин с измерениями и планом исправлений. После изменения запроса, индекса или границ транзакции повторяют замеры в сопоставимых условиях. Проверяют не только ускорение выбранной операции, но и влияние на запись, ожидания и соседние запросы. Такой подход позволяет отличить устойчивое улучшение от случайного снижения нагрузки.