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

Дата публикации: 28-09-2026 04:42:15

Каждые 5 минут транзакции в PostgreSQL замирают на 3-7 секунд. Разбор кривого механизма сброса WAL на диск.
В высоконагруженных системах с интенсивным IO наступает момент, когда p99 латентность запросов улетает в космос, а мониторинг дисковой подсистемы фиксирует дикий пик util до 100%. При этом графики CPU и памяти выглядят вполне мирно. Виновник - дефолтная конфигурация PostgreSQL подсистемы чекпоинтов.
При дефолтном значении max_wal_size в 1 ГБ и min_wal_size в 80 МБ ядро СУБД работает в режиме постоянного стресса. Как только объем измененных данных (dirty pages) превышает лимит, бэкграунд-процесс checkpointer начинает экстренно сбрасывать грязные страницы в файлы данных. По умолчанию параметр checkpoint_completion_target равен 0.5. Это значит, что PostgreSQL пытается выплюнуть весь накопленный гигабайт (или несколько) за половину отведенного времени до следующего чекпоинта. На дисках со средней производительностью это порождает лавинообразный поток синхронных операций fsync, забивая очередь устройств и вешая любые транзакции, ожидающие commit.
Вторая проблема кроется в операционной системе. Дефолтный планировщик ввода-вывода и параметры ядрового лимита dirty_background_ratio / dirty_ratio заставляют Linux копить грязные страницы в page cache до определенного порога, а затем устраивать лавинообразный сброс (flush), во время которого блокируются системные вызовы записи. В итоге СУБД и ядро ОС устраивают двойной шторм записи.
Как это лечить на уровне конфигурации PostgreSQL и Linux:
1. Увеличиваем max_wal_size до адекватных значений (например, 16GB - 64GB в зависимости от объема SSD и Write-Intensive нагрузки), чтобы чекпоинты срабатывали реже и давали большой интервал времени для размазывания нагрузки.
2. Выкручиваем checkpoint_completion_target в 0.9. Это заставляет чекпоинт равномерно распределять сброс грязных страниц почти на 90% времени цикла, убирая микрофризы.
3. Настраиваем ядро Linux через sysctl: уменьшаем vm.dirty_background_ratio до 5-10 и vm.dirty_ratio до 20-30, чтобы ОС сбрасывала кэш на накопитель мелкой непрерывной «пылью», а не гигантскими блоками.
4. Используем планировщик mq-deadline или none для NVMe-накопителей, чтобы избежать сериализации запросов ввода-вывода.
Игнорирование этих параметров на продакшене с утилизацией записи от 500 MB/s приводит к деградации SLA, таймаутам в пуле соединений и потере денег на простоях.
- Инфраструктурный аудит и калькулятор 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 кластер словно падает в обморок ...	0	8.03	27-09-2026
3	База данных захлебывается в дисковом I/O wait, хотя на сервере ...	0	8.6	26-09-2026
4	База данных захлебывается в дисковом I/O wait, хотя на сервере ...	0	8.41	26-09-2026
5	🧠 Великий жор ОЗУ: от космических свердержав до цифрового ожирения ...	0	13.95	28-09-2026
6	Recovering a Morpheus Appliance from MySQL InnoDB Corruption	0	7.64	26-09-2026
7	Running OpenBao on Kubernetes with a CloudNativePG PostgreSQL backend	0	10.75	16-09-2026
8	Сколько на самом деле стоит путь пакета через ядро Linux, ...	0	7.07	28-09-2026
9	Issues with fiber channel multipathing on HPE ProLiant DL385?	0	8.78	27-09-2026
10	Новости науки свайпами: serverless на AWS, LLM за цент на статью и 12 тестировщиков для Google Play	0	8.77	27-09-2026

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