Мониторинг PostgreSQL 19 — что изменится на практике

PostgreSQL 19 приближается к выходу и добавляет несколько точечных, но ощутимых улучшений в observability. Основные правки касаются видимости блокировок, гибкости логирования по типам процессов, разделения настроек для VACUUM и ANALYZE, а также учета реального объема полностраничных записей в WAL. Эти изменения стоит изучить командам, которые уже активно используют логи и pg_stat_ для расследования проблем. observability здесь означает способность системы предоставлять данные о своем состоянии, чтобы администраторы могли быстро находить узкие места и сбои. pg_stat_ — это набор системных представлений, которые хранят статистику по запросам, блокировкам и работе фоновых процессов. Для команд, решающих вопрос обновления, важно понимать, что новые возможности снижают ручной труд по настройке и дают более точную картину нагрузки без дополнительных инструментов. Это особенно актуально, когда уже используются самописные сборщики метрик и строгие политики хранения логов: при обновлении можно избежать разрывов в мониторинге и сразу получить данные для планирования ресурсов.

В предыдущих версиях log_lock_waits по умолчанию был выключен. Теперь он включен из коробки. Любой сеанс, который ждет блокировку дольше deadlock_timeout, сразу попадает в лог. Это дает дешевый детектор contention без необходимости вручную включать параметр на всех инстансах. Contention — это ситуация, когда несколько процессов одновременно пытаются получить доступ к одним и тем же данным и мешают друг другу. Для нагрузок с частыми длинными транзакциями или сложными блокировками это сразу покажет проблемные места, которые раньше оставались скрытыми. При этом проверка deadlock по-прежнему остается дорогой операцией, поэтому значение deadlock_timeout по-прежнему важно подбирать под типичные времена транзакций. Командам стоит оценить, насколько часто у них возникают ожидания блокировок: если такие случаи редки, включение по умолчанию почти не повлияет на производительность, но даст ранний сигнал о росте конкуренции за ресурсы. Если же транзакции обычно короткие, можно оставить таймаут на прежнем уровне и получить предупреждения только о реальных проблемах. Это помогает решить, стоит ли готовить обновление именно ради лучшей видимости блокировок или можно подождать следующего релиза.

Гибкая настройка уровня логов по процессам

Раньше log_min_messages был единой настройкой на весь кластер. Чтобы получить детальный вывод от checkpointer, приходилось мириться с таким же уровнем от всех остальных процессов. Checkpointer — это фоновый процесс, который периодически сбрасывает измененные страницы на диск, чтобы уменьшить объем WAL при восстановлении. В 19 версии параметр принимает список пар «тип процесса:уровень» плюс обязательный базовый уровень для остальных. Это позволяет, например, оставить WARNING для большинства процессов, но поднять DEBUG2 только для checkpointer и DEBUG1 для autovacuum. Autovacuum — автоматическая очистка устаревших версий строк, которая работает в фоне. Список поддерживаемых типов охватывает archiver, bgwriter, walreceiver и другие. Archiver копирует файлы WAL на резервное хранилище, bgwriter записывает грязные страницы в фоновом режиме, а walreceiver принимает изменения на реплике. При миграции старые конфиги продолжат работать, однако новые возможности пригодятся при отладке конкретных фоновых процессов без замусоривания общего лога. Для решения о внедрении важно, что теперь можно точечно повысить детализацию только там, где есть подозрение на проблему, и не увеличивать нагрузку на диск и анализ логов по всему кластеру. Если команда часто расследует задержки чекпоинтов или автovacuum, это изменение снижает риск пропустить важные события и упрощает поддержку строгих политик логирования.

Разделение контроля за автоанализом и вакуумом

До 19 версии log_autovacuum_min_duration управлял логированием и VACUUM, и ANALYZE. VACUUM удаляет устаревшие версии строк и освобождает место, а ANALYZE собирает статистику для планировщика запросов. Поскольку autoanalyze обычно короче, порог, настроенный под вакуум, почти всегда отбрасывал записи об анализе. Теперь появился отдельный log_autoanalyze_min_duration. Оба параметра по умолчанию равны 10 минутам и допускают значения 0 и -1. Можно задать per-table переопределение, то есть разные пороги для отдельных таблиц. При обновлении нужно проверить скрипты и дашборды, которые парсят автovacuum-логи: теперь они будут видеть только вакуум, если не добавить учет нового параметра. Для команд, решающих, брать ли обновление, важно оценить, насколько часто autoanalyze занимает значительное время и влияет на производительность. Если статистика обновляется редко или быстро, раздельные пороги позволят получать только релевантные записи и не перегружать систему логирования. Это снижает риск упустить медленные операции очистки и помогает точнее планировать обслуживание больших таблиц.

Учет объема полностраничных записей и новые события ожидания

Вакуум часто генерирует много полностраничных образов WAL, но раньше размер этих образов не логировался напрямую. WAL — журнал предзаписи, куда записываются все изменения перед тем, как они попадут на диск. Полностраничные образы (FPI) сохраняют всю страницу целиком при первом изменении после чекпоинта, чтобы обеспечить целостность при восстановлении. PostgreSQL 19 добавляет счетчик wal_fpi_bytes в pg_stat_wal, EXPLAIN (ANALYZE, WAL) и в вывод VACUUM/ANALYZE. Сравнение wal_fpi_bytes с общим wal_bytes сразу показывает долю полностраничных записей и помогает понять, стоит ли включать wal_compression или менять расписание чекпоинтов. Появились также новые события ожидания WaitForWalWrite и расширение WaitForWalFlush на реплики. Эти события показывают, сколько времени процессы тратят на ожидание записи или сброса WAL. В российских контурах, где часто используют самописные сборщики метрик и строгие политики логирования, эти данные помогут точнее планировать диск под WAL и заранее выявлять узкие места без pg_waldump. Перед обновлением стоит проверить, как текущие инструменты обрабатывают новые поля в логах и статистике, чтобы избежать разрывов в мониторинге после апгрейда. Если доля полностраничных записей уже заметна, новые метрики дадут объективную причину для изменения настроек сжатия или частоты чекпоинтов, что особенно важно при ограниченном бюджете на хранилище.

Источник

Это краткий разбор материала ClickHouse. Полная версия с примерами кода, схемами и деталями реализации — в оригинале: Мониторинг PostgreSQL 19 — что изменится на практике.

Курс по теме — Построение DWH на ClickHouse