Диагностика высококардинальных нагрузок в pg_stat_statements: как выявить вымывание кэша и непараметризованные запросы в PostgreSQL

Диагностика высококардинальных нагрузок в pg_stat_statements: как выявить вымывание кэша и непараметризованные запросы в PostgreSQL

Расширение pg_stat_statements является де-факто отраслевым стандартом мониторинга и профилирования запросов в СУБД PostgreSQL. Оно нормализует исполняемый SQL-код, заменяя константные литералы на позиционные параметры, рассчитывает суммарное время исполнения, число чтений с диска и обращений к разделяемой памяти. Однако в условиях высококардинальных нагрузок (High Cardinality Workloads) расширение способно потерять свою эффективность, искажая статистику и скрывая наиболее проблемные участки системы.

В шестой части цикла исследований «Postgres in Production» архитектор данных pganalyze Райан Буз (Ryan Booz) детально разбирает механику деградации хэш-таблицы pg_stat_statements, влияние ORM-библиотек и динамического SQL, а также предлагает пошаговый алгоритм диагностики и устранения вымывания кэша.

Что такое высокая кардинальность с точки зрения pg_stat_statements

В контексте профилирования баз данных под высокой кардинальностью понимается ситуация, когда приложение непрерывно генерирует больше уникальных нормализованных запросов, чем способна вместить внутренняя память расширения, заданная параметром pg_stat_statements.max (по умолчанию 5000 записей).

Хотя разработчики часто предполагают, что их проект выполняет фиксированный набор шаблонных операций, современные инструменты скрывают генерацию сотен тысяч уникальных конструкций:

• Динамические списки в условиях IN (...): до версии PostgreSQL 17 включительно парсер считал предикаты WHERE id IN ($1) и WHERE id IN ($1, $2, $3) разными запросами. Каждая новая длина списка создавала отдельную строку в кэше.
• ORM и multi-tenant архитектуры: объектно-реляционные отображения (Prisma, Hibernate, TypeORM) нередко подставляют схемы, имена таблиц или фильтры арендаторов динамически, исключая параметризацию.
• Ad-hoc запросы и ИИ-инструменты: современные ассистенты и BI-системы опрашивают метаданные базы тысячами неповторяющихся вариаций SELECT.
• Включение track_utility: при значении pg_stat_statements.track_utility = on утилитарные команды (VACUUM, CREATE INDEX, разовые миграции) забивают хэш-таблицу.

[Поток динамических запросов] ---> [Хэш-таблица pg_stat_statements (Лимит max=5000)]
                                           |
                                           v  Переполнение!
                       [Вытеснение (Deallocation)] ---> Потеря медленных запросов

Механика вымывания кэша и деаллокаций

Когда хэш-таблица заполняется до предела (обычно порог составляет 95% от pg_stat_statements.max), расширение запускает алгоритм очистки: оно принудительно удаляет записи с наименьшим числом вызовов, освобождая место для новых входящих запросов. Этот процесс фиксируется счетчиком deallocations.

Опасность заключается в эффекте «вымывания»:

1. Высокочастотный поток мелких непараметризованных вставок быстро заполняет свободные слоты памяти.
2. Редкий, но крайне тяжелый аналитический запрос, выполняющийся раз в сутки и потребляющий 100% CPU в течение 10 минут, имеет малое число вызовов.
3. Алгоритм вытеснения ошибочно маркирует тяжелый запрос как кандидата на удаление и стирает его из статистики.
4. Инженер открывает мониторинг и не видит реального источника деградации базы данных.

Эксперимент: Postgres 17 против Postgres 18 на синтетической нагрузке Bluebox

Для наглядной демонстрации проблемы был проведен стресс-тест открытой базы данных Bluebox с набором из 30 типовых сценариев (менее 50 уникальных параметризованных шаблонов). Единственное отличие заключалось в наличии сценария batch_film_lookup, запрашивающего от 1 до 200 идентификаторов через WHERE film_id IN (...).

В PostgreSQL 18 встроен алгоритм схлопывания произвольных списков IN (...) в единую нормализованную форму. Наличие двух записей вместо одной в PG 18 объясняется тем, что клиентские драйверы при первом вызове отправляют обобщенный тип (numeric), а после ответа сервера корректируют его на точный integer.

Пять шагов диагностики здоровья pg_stat_statements

Чтобы определить, теряет ли ваша база данных ключевые метрики производительности, выполните следующие проверки:

Шаг 1. Проверка счетчика деаллокаций через системный view

Выполните SQL-запрос к системному представлению pg_stat_statements_info:

SELECT 
    deallocations, 
    stats_reset 
FROM pg_stat_statements_info;

Если значение deallocations непрерывно растет в течение дня, расширение работает в режиме постоянной нехватки памяти и теряет запросы.

Шаг 2. Оценка степени заполнения хэш-таблицы

Сравните текущее количество отслеживаемых запросов с установленным лимитом:

SELECT 
    count(*) AS current_entries,
    current_setting('pg_stat_statements.max')::int AS max_entries,
    round((count(*)::numeric / current_setting('pg_stat_statements.max')::numeric) * 100, 2) AS fill_percent
FROM pg_stat_statements;

Значение fill_percent выше 90-95% сигнализирует о постоянном риске вытеснения.

Шаг 3. Замер скорости повторного заполнения после сброса

В тестовом окружении или во время технологического окна сбросьте накопленные счетчики и засеките время:

SELECT pg_stat_statements_reset();

Если таблица на 5000 или 10 000 записей повторно заполняется менее чем за 30–60 минут, ваш профиль нагрузки страдает от экстремальной кардинальности.

Шаг 4. Поиск известных медленных запросов по префиксу

Если вы точно знаете, что в приложении выполняется тяжелая процедура, но запрос не удается найти по сигнатуре текста:

SELECT query, calls, total_exec_time 
FROM pg_stat_statements 
WHERE query ILIKE '%orders_aggregate_report%'
LIMIT 5;

Пустой результат при регулярном выполнении кода в продакшене прямо доказывает факт его вытеснения.

Шаг 5. Мониторинг стабильности Top-10 по суммарному времени

Отсортируйте запросы по total_exec_time. Если состав первой десятки кардинально меняется каждые 15 минут при неизменном профиле пользовательской активности, расширение непрерывно сбрасывает историю.

Инженерные методы устранения высокой кардинальности

Для восстановления достоверности мониторинга необходимо устранить первопричины на уровне приложения и конфигурации СУБД:

1. Переход на = ANY(...) вместо IN (...): Замените динамическую конкатенацию строк в ORM на передачу типизированного массива:

   -- Антипаттерн (порождает N уникальных записей)
   SELECT * FROM users WHERE id IN (1, 2, 3, 4);
   
   -- Оптимальный паттерн (всегда одна запись в кэше)
   SELECT * FROM users WHERE id = ANY($1::int[]);
   

2. Параметризация литералов: полностью исключите прямую подстановку чисел и строк в тело запроса. Все динамические значения обязаны передаваться через PREPARE или клиентские плейсхолдеры ($1, $2).
3. Корректировка конфигурации postgresql.conf:
   • Увеличьте pg_stat_statements.max до 10 000–20 000 (учитывая, что каждая запись требует около 1–2 КБ разделяемой памяти);
   • Отключите трекинг утилит: pg_stat_statements.track_utility = off;
   • Установите pg_stat_statements.track = top, чтобы игнорировать промежуточные вложенные вызовы внутри PL/pgSQL функций, если они создают паразитный шум.
4. Планирование обновления до PostgreSQL 18: новая версия штатно устраняет главную причину разрастания кэша при работе с массивами идентификаторов.

Грамотная настройка pg_stat_statements гарантирует, что оптимизационные усилия команды будут направлены на реальные узкие места базы данных, а не на борьбу со слепыми зонами мониторинга.