Каждые 5 минут транзакции в PostgreSQL замирают на 3 - ...

Дата публикации: 21-09-2026 22:23:29

Каждые 5 минут транзакции в PostgreSQL замирают на 3 - 7 секунд. В логах тишина, CPU не нагружен, а клиенты отваливаются по таймауту. Если вы видите такие микрофризы, значит, ваш чекпоинтер сошел с ума.
Проблема кроется в дефолтных настройках `max_wal_size` и агрессивном поведении `checkpoint_timeout`. По умолчанию PostgreSQL считает, что 1 Гб WAL или 5 минут работы - это повод для запуска чекпоинта. В высоконагруженных системах это приводит к тому, что в момент X база начинает форсированно сбрасывать все накопившиеся dirty pages из оперативной памяти на диск.
Результат: IO-стек захлебывается. Дисковая очередь улетает в космос, latency записи растет экспоненциально, и пока ядро Linux не разгребет очередь запросов к блочному устройству, база «замораживает» выполнение транзакций. Это типичный пример того, как «безопасные» дефолты убивают производительность на продакшене.
Как лечить:
1. Размазывание записи через `checkpoint_completion_target`. По умолчанию стоит 0.9, и это хорошо. Этот параметр определяет, какую часть времени между чекпоинтами база будет тратить на фоновую запись страниц. Если вы поставите 0.9, PostgreSQL будет растягивать сброс dirty pages на 90% времени до следующего чекпоинта. Не трогайте его, если не понимаете, что делаете.
2. Увеличение `max_wal_size`. Дефолтный 1 Гб - это смешно. Для нагруженных баз ставьте 16 Гб, 32 Гб или даже 64 Гб. Это даст чекпоинтеру больше пространства для маневра и позволит избежать частых принудительных сбросов. Главное - следите за объемом диска, так как WAL занимает место.
3. Тюнинг `bgwriter`. Настройте `bgwriter_delay` и `bgwriter_lru_maxpages`. Задача фонового писателя - сбрасывать страницы на диск постепенно, чтобы чекпоинтеру в момент Y оставалось меньше работы. Если `bgwriter` работает эффективно, чекпоинт пройдет незаметно.
4. Мониторинг. Смотрите в `pg_stat_bgwriter`. Если параметр `checkpoints_timed` сильно превышает `checkpoints_req`, значит, база живет по таймеру и это хорошо. Если же `checkpoints_req` растет быстро - вы упираетесь в `max_wal_size` и база сбрасывает данные чаще, чем планировалось.
Микрофризы в Postgres - это не магия, это следствие неумения базы работать с дисковым IO в условиях дефолтных ограничений. Настройте `max_wal_size` под реальный объем записи, убедитесь, что `checkpoint_completion_target` равен 0.9, и ваш IO-стек скажет спасибо.
- Инфраструктурный аудит и калькулятор TCO кластера: @Personnel_run_bot (/tma)
- База знаний и разборы: ftops.space
- ftops.space | Run-As-Daemon Infrastructure

Схожие новости

#	Наименование новости	Тональность	Информативность	Дата публикации
1	Каждые 5 минут транзакции в PostgreSQL замирают на 3-7 секунд. ...	-1	8.77	21-09-2026
2	Каждые 5 минут транзакции в PostgreSQL замирают на 3 - ...	0	12.14	19-09-2026
3	[Перевод] Статистика PostgreSQL: почему запросы выполняются медленно	0	7.74	19-08-2026
4	PostgreSQL 19 Beta 2 Released!	5	7	16-07-2026
5	PostgreSQL для бэкендера: 10 фич, которыми мало пользуются, а зря	5	7	30-06-2026
6	PostgreSQL для бэкендера: 10 фич, которыми мало пользуются, а зря	5	7	30-06-2026
7	Ваши тесты медленные не из-за базы данных. Я измерил	0	9.6	15-06-2026
8	Кто выгрузил платежи, или Пример расследования инцидента на аудите в Postgres Pro Enterprise	0	7	10-07-2026
9	Очередь задач на Postgres: SKIP LOCKED + lease/heartbeat + backpressure (практический опыт)	0	12.42	13-01-2026

Классификация: Мнения. Схожих патентов: 0. Схожих новостей: 9. Тональность: 0. Информативность: 11.17. Источник: vk.com.