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

Дата публикации: 21-09-2026 03:09:07

Каждые 5 минут транзакции в PostgreSQL замирают на 3-7 секунд. Это не магия и не «тяжелый запрос». Это классический Checkpoint Spike, вызванный дефолтными настройками, которые в 2024 году выглядят как диверсия против продакшена.
Когда база данных достигает `max_wal_size` или проходит интервал `checkpoint_timeout` (по умолчанию 5 минут), Postgres начинает агрессивный сброс dirty pages из оперативной памяти на диск. Проблема в том, что по дефолту он делает это максимально быстро, чтобы как можно скорее вернуться к штатной работе. В итоге IO-подсистема захлебывается, очередь записи (iowait) улетает в космос, а все пишущие транзакции встают в блокировку.
Как диагностировать? Смотрите логи: "checkpoint starting: time", а следом через пару секунд "checkpoint complete". Если между ними проходит больше пары секунд, вы теряете производительность.
Как лечить? Рецепт один - размазывание нагрузки.
1. Увеличиваем `max_wal_size`. Дефолтные 1GB - это смешно. Для современных NVMe накопителей ставьте 16GB, 32GB или даже 64GB. Больше WAL - реже чекпоинты, меньше суммарный IOPS на запись.
2. Настраиваем `checkpoint_completion_target`. Это самый важный параметр. По умолчанию он равен 0.5. Это значит, что Postgres пытается сбросить все dirty pages за 50% времени между чекпоинтами. Если интервал 5 минут, он будет "жарить" 2.5 минуты, а потом 2.5 минуты отдыхать. Ставьте 0.9. Тогда Postgres будет делать это плавно на протяжении почти всего интервала, не создавая пиковых нагрузок на диск.
3. Тюним `bgwriter`. Чтобы чекпоинт не был таким "грязным", заставьте `bgwriter` работать активнее в фоне. Параметры `bgwriter_delay` (200ms), `bgwriter_lru_maxpages` (400) и `bgwriter_lru_multiplier` (4.0) помогут выталкивать страницы на диск постепенно, пока нагрузка минимальна.
Что по деньгам? TCO кластера с неправильно настроенными чекпоинтами растет за счет необходимости покупки более дорогих IOPS-интенсивных дисков. Настройка WAL позволяет сэкономить до 20-30% бюджета на хранилище, переводя нагрузку из "пиковой" в "линейную".
Если ваша база данных держит интенсивный OLTP, не ждите, пока пользователи начнут жаловаться на лаги. Проверьте `checkpoint_completion_target` прямо сейчас.
- Инфраструктурный аудит и калькулятор TCO кластера: @Personnel_run_bot (/tma)
- База знаний и разборы: ftops.space
- ftops.space | Run-As-Daemon Infrastructure

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

#	Наименование новости	Тональность	Информативность	Дата публикации
1	Postgresso 4 (89)	0	13.18	10-06-2026
2	PostgreSQL для бэкендера: 10 фич, которыми мало пользуются, а зря	5	7	30-06-2026
3	Кто выгрузил платежи, или Пример расследования инцидента на аудите в Postgres Pro Enterprise	0	7	10-07-2026
4	Очередной разбор полетов в 03:00. Мониторинг Cilium показывает низкую загрузку ...	0	9.21	21-09-2026
5	Linux наконец-то не тормозит или пятничный релакс	0	13.18	07-08-2026
6	Поверхностный мониторинг облачных провайдеров привычно обвиняет приложение в утилизации ресурсов, ...	0	7.98	20-09-2026
7	Как отговорить себя от написания своей ФС	0	11.64	09-08-2026
8	Ingestion and query issues for logs, spans, traces in US	0	7.58	01-07-2026
9	Span & Transaction ingestion delayed in DE	0	6.95	13-08-2026
10	https://dzen.ru/a/anBP3WTg8Wn46JCl Народ часто спрашивает: «А на чём всё это крутить?». ...	0	12.9	06-08-2026

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