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

Дата публикации: 29-09-2026 17:42:44

Каждые 5 минут транзакции в PostgreSQL замирают на 3-7 секунд. Разбор кривого механизма сброса WAL на диск.
В высоконагруженных системах с интенсивным IO наступает момент, когда p99 латентность запросов улетает в космос, хотя CPU и диск по метрикам недогружены. Причина кроется в дефолтных настройках PostgreSQL, а именно в механизме контрольных точек, или checkpoints. Когда фоновый процесс checkpointer решает, что накопилось слишком много измененных страниц в буферном пуле, он запускает жесткий сброс всего пула на накопитель.
По умолчанию параметр `max_wal_size` установлен на скромные 1 ГБ, а `checkpoint_completion_target` равен 0.9. Это означает, что сервер обязан выплюнуть весь накопленный объем dirty pages на диск за 90% от отведенного на интервал времени. Если у вас интенсивный пайплайн вставок и обновлений, этот гигабайт забивается за секунды. В результате checkpointer начинает молотить на максимальной скорости, упираясь в пропускную способность дисковой подсистемы.
Операционная система в этот момент начинает захлебываться. Буферы страниц переполняются, и бэкэнды, пишущие новые данные, сами вовлекаются в синхронный сброс накопившихся грязных страниц через `fsync`. Образуется гигантская очередь запросов к блочному устройству. Ядро Linux сбрасывает кэш страниц на диск блоками, вызывая лавинообразный рост `iowait` и те самые микрофризы на несколько секунд, во время которых база данных просто не отвечает на новые соединения и запросы.
Чтобы база не замирала, нужно размазать нагрузку по времени и заставить checkpointer работать плавно, а не пачками. Первое действие - поднять `max_wal_size` до адекватных для современного железа значений, например до 32 - 64 ГБ. Это увеличит интервал между чекпоинтами и даст системе больший простор для фоновой записи.
Второе действие - настроить параметр `checkpoint_completion_target = 0.95`, чтобы процесс растягивал запись на практически весь доступный интервал. Также критически важно зафиксировать размер сегмента через `min_wal_size`, чтобы избежать лишних аллокаций на диске. На уровне операционной системы стоит проверить параметры `vm.dirty_background_ratio` и `vm.dirty_ratio`, чтобы ядро Linux не устраивало внезапный глобальный сброс памяти в самый неподходящий момент.
- Инфраструктурный аудит и калькулятор TCO кластера: @Personnel_run_bot (/tma)
- База знаний и разборы: ftops.space
- ftops.space | Run-As-Daemon Infrastructure

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

#	Наименование новости	Тональность	Информативность	Дата публикации
1	Каждые пять минут высоконагруженная база данных в PostgreSQL словно проваливается ...	1	8.42	29-09-2026
2	Каждые 5 минут транзакции в PostgreSQL замирают на 3 - ...	-1	11.86	28-09-2026
3	Каждые пять минут нагруженный PostgreSQL кластер словно падает в обморок ...	0	7.98	28-09-2026
4	Каждые пять минут нагруженный PostgreSQL кластер словно падает в обморок ...	0	8.03	27-09-2026
5	База данных захлебывается в дисковом I/O wait, хотя на сервере ...	0	8.6	26-09-2026
6	База данных захлебывается в дисковом I/O wait, хотя на сервере ...	0	8.41	26-09-2026
7	Postgres Professional представила Postgres Pro Enterprise Manager 2.10 с анализатором нагрузки Healthcheck Advisor	0	10.4	29-09-2026
8	Running OpenBao on Kubernetes with a CloudNativePG PostgreSQL backend	0	10.75	16-09-2026
9	Облачные провайдеры берут плату не за железо, а за лень ...	0	14.96	28-09-2026

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