Каждые 5 минут транзакции в PostgreSQL замирают на 3 - 7 секунд. Разбор кривого механизма сброса WAL на диск.
Производительность базы данных выглядит идеальной, пока нагрузка не упирается в дефолтный checkpoint в PostgreSQL. При стандартном значении `max_wal_size = 1GB` ядро базы начинает панически сбрасывать грязные страницы (dirty pages) на накопитель, как только исчерпывается этот лимит или истекает таймер `checkpoint_timeout = 5min`. В этот момент дисковая подсистема получает лавинообразную запись, а IOPS упирается в потолок.
Результат - классический микрофриз. Очередь запросов растет, клиенты получают таймауты, а метрика `checkpoint_write_time` в системных представлениях улетает в космос. Проблема усугубляется тем, что фоновый процесс сброса (`bgwriter`) настроен слишком консервативно и перекладывает всю тяжелую работу на сам чекпоинт.
Чтобы избавиться от фризов, нужно заставить базу размазывать нагрузку на запись во времени, а не устраивать дисковый шторм раз в пять минут.
1. Увеличиваем объем WAL-файлов до адекватных значений под вашу емкость дисков:
`max_wal_size = '16GB'`
`min_wal_size = '2GB'`
2. Растягиваем интервал между чекпоинтами, снижая пиковую интенсивность записи:
`checkpoint_timeout = '30min'`
3. Управляем агрессивностью сброса через `checkpoint_completion_target`. Значение `0.9` означает, что PostgreSQL постарается равномерно распределить запись 90% времени от заданного таймаута:
`checkpoint_completion_target = 0.9`
4. Тюним фоновый писатель (`bgwriter`), чтобы он зачищал буферы заранее:
`bgwriter_delay = 20ms`
`bgwriter_lru_maxpages = 200`
`bgwriter_lru_multiplier = 3.0`
Мониторите ли вы поведение чекпоинтов через `pg_stat_bgwriter` или ваша инфраструктура до сих пор живет на дефолтах? Делитесь в комментариях.
- Инфраструктурный аудит и калькулятор 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 | [Перевод] Статистика PostgreSQL: почему запросы выполняются медленно | 0 | 7.74 | 19-08-2026 |
| 3 | PostgreSQL 19 Beta 2 Released! | 5 | 7 | 16-07-2026 |
| 4 | Кто выгрузил платежи, или Пример расследования инцидента на аудите в Postgres Pro Enterprise | 0 | 7 | 10-07-2026 |
| 5 | PostgreSQL для бэкендера: 10 фич, которыми мало пользуются, а зря | 5 | 7 | 30-06-2026 |
| 6 | [Перевод] Нетипичные оптимизации в PostgreSQL, или Креативное ускорение запросов | 0 | 8.21 | 02-03-2026 |
| 7 | Ваши тесты медленные не из-за базы данных. Я измерил | 0 | 9.6 | 15-06-2026 |
| 8 | The Real Operational Cost of Vacuuming in PostgreSQL | 0 | 10.7 | 08-02-2026 |
| 9 | Очередь задач на Postgres: SKIP LOCKED + lease/heartbeat + backpressure (практический опыт) | 0 | 12.42 | 13-01-2026 |