Каждые пять минут нагруженный PostgreSQL кластер словно падает в обморок ...

Дата публикации: 28-09-2026 17:14:58

Каждые пять минут нагруженный PostgreSQL кластер словно падает в обморок - транзакции замирают на три-семь секунд, соединения висят на пуле, а p99 latency улетает в космос. Причина кроется в дефолтных настройках механизма checkpoint, который вместо непрерывного сброса данных на диск устраивает лавинообразный сброс грязных страниц.
Под капотом базы данных работает process под названием Checkpointer. Его задача - гарантировать, что данные из оперативной памяти shared_buffers попадут на постоянный накопитель NVMe, чтобы при аварийном перезапуске не пришлось перечитывать гигабайты WAL с нулевой точки. По умолчанию параметр max_wal_size выставлен в жалкие 1 гигабайт. Как только интенсивный write-heavy поток трафика заполняет этот гигабайт, PostgreSQL мгновенно выставляет флаг форсированного чекпоинта.
Дальше начинается дисковый шторм. Checkpointer пытается выплюнуть на накопитель гигабайты грязных страниц памяти через параметр checkpoint_completion_target. По умолчанию он равен 0.5. Это значит, что база обязана завершить сброс грязных буферов за половину времени до следующего чекпоинта. При коротком интервале и дефолтном размере дисковая подсистема упирается в 100-процентную утилизацию IOPS. Ядро Linux через page cache начинает агрессивно сбрасывать фоновые writeback-потоки, забивая очередь контроллера диска. В этот момент фоновые процессы записи бьются о barriers, а новые транзакции блокируются в ожидании освобождения буферов shared_buffers.
Решением проблемы является полный пересчет параметров под реальное железо и нагрузку.
Первое - поднимаем размер WAL-сегментов, чтобы чекпоинты происходили не по таймеру заполнения объема, а по времени. Устанавливаем max_wal_size на уровне 32-64 гигабайт, а min_wal_size не менее 4-8 гигабайт. Это размажет запись во времени и позволит диску дышать.
Второе - заставляем базу сбрасывать страницы плавно. Меняем checkpoint_completion_target на 0.9. Теперь Checkpointer будет растягивать процесс записи на 90% времени между чекпоинтами, снижая пиковую нагрузку на дисковый контроллер в разы.
Третье - настраиваем операционную систему. В sysctl.conf фиксируем параметры ядра для грязных страниц:
vm.dirty_background_ratio = 5
vm.dirty_ratio = 10
Это заставит ядро Linux начинать фоновый сброс page cache гораздо раньше, исключая момент внезапного лавинообразного затыка на уровне VFS.
На реальном кластере с NVMe enterprise-класса правильная настройка этих четырех параметров срезает инфраструктурный TCO за счет утилизации купленного железа на 100% и ликвидации ложных простоев процессора во время пиков, экономя сотни часов работы инженеров на разбор инцидентов.
- Инфраструктурный аудит и калькулятор TCO кластера: @Personnel_run_bot (/tma)
- База знаний и разборы: ftops.space
- ftops.space | Run-As-Daemon Infrastructure

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

#	Наименование новости	Тональность	Информативность	Дата публикации
1	Каждые 5 минут транзакции в PostgreSQL замирают на 3 - ...	-1	11.86	28-09-2026
2	Каждые пять минут высоконагруженная база данных в PostgreSQL словно проваливается ...	1	8.42	29-09-2026
3	Каждые пять минут нагруженный PostgreSQL кластер словно падает в обморок ...	0	8.03	27-09-2026
4	База данных захлебывается в дисковом I/O wait, хотя на сервере ...	0	8.6	26-09-2026
5	База данных захлебывается в дисковом I/O wait, хотя на сервере ...	0	8.41	26-09-2026
6	Сколько на самом деле стоит путь пакета через ядро Linux, ...	0	7.07	28-09-2026
7	Облачные провайдеры берут плату не за железо, а за лень ...	0	14.96	28-09-2026
8	Running OpenBao on Kubernetes with a CloudNativePG PostgreSQL backend	0	10.75	16-09-2026
9	OpenTelemetry everywhere: Migrating a metrics platform at scale	0	8.98	17-09-2026
10	Новости науки свайпами: serverless на AWS, LLM за цент на статью и 12 тестировщиков для Google Play	0	8.77	27-09-2026

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