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

Дата публикации: 30-09-2026 01:54:57

Каждые 5 минут транзакции в PostgreSQL замирают на 3-7 секунд. Разбор кривого механизма сброса WAL на диск.
В высоконагруженных системах с интенсивным IO наступает момент, когда p99 латентность запросов улетает в космос, а мониторинг диска показывает дикие пики записи, хотя внешне поток транзакций стабилен. Причина кроется в дефолтных настройках PostgreSQL, а именно в агрессивном поведении чекпоинтера при исчерпании `max_wal_size` (по умолчанию убогие 1 GB) или срабатывании таймера `checkpoint_timeout` (5 минут).
Когда объем измененных страниц в shared buffers превышает лимит, фоновый процесс `Checkpointer` начинает сбрасывать грязные страницы (dirty pages) на накопитель. Но делает это не плавно, а залпом. На дефолтных параметрах процессор выплевывает в дисковую подсистему гигабайты данных за считанные секунды. Storage упирается в iowait, очередь к устройствам забивается, и ядро Linux блокирует процессы в системных вызовах записи. База ловко падает в пятисекундный микрофриз, а клиентские приложения получают таймауты.
Чтобы победить это безобразие, нужно заставить базу размазывать нагрузку во времени. Первый шаг - поднять `max_wal_size` до адекватных значений (например, 16 - 64 GB), чтобы чекпоинт запускался реже и давал больший простор для маневра. Второй - настроить параметр `checkpoint_completion_target` на значение 0.9. Это заставит чекпоинтер растягивать процесс сброса грязных страниц на 90% от отведенного времени `checkpoint_timeout`, вместо того чтобы палить изо всех пушек в первые же минуты.
На уровне операционной системы тоже не обойтись без тюнинга ядра Linux. Крутите `vm.dirty_background_ratio` (выставляйте на 5-10%) и `vm.dirty_ratio` (20-30%), чтобы page cache не забивался под завязку перед тем, как отдать приоритет синхронному сбросу. Добавьте к этому планировщик ввода-вывода `bfq` или `mq-deadline` для NVMe-накопителей, и ваши базы перестанут спотыкаться на ровном месте.
- Инфраструктурный аудит и калькулятор TCO кластера: @Personnel_run_bot (/tma)
- База знаний и разборы: ftops.space
- ftops.space | Run-As-Daemon Infrastructure

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

#	Наименование новости	Тональность	Информативность	Дата публикации
1	Каждые 5 минут транзакции в PostgreSQL замирают на 3-7 секунд. ...	0	8.8	29-09-2026
2	Каждые 5 минут транзакции в PostgreSQL замирают на 3-7 секунд. ...	0	11.43	28-09-2026
3	Каждые пять минут высоконагруженная база данных в PostgreSQL словно проваливается ...	1	8.42	29-09-2026
4	Каждые 5 минут транзакции в PostgreSQL замирают на 3 - ...	-1	11.86	28-09-2026
5	Каждые пять минут нагруженный PostgreSQL кластер словно падает в обморок ...	0	7.98	28-09-2026
6	Каждые пять минут нагруженный PostgreSQL кластер словно падает в обморок ...	0	8.03	27-09-2026
7	База данных захлебывается в дисковом I/O wait, хотя на сервере ...	0	8.6	26-09-2026
8	У вас 64 ядра и 256 ГБ памяти, но Nginx ...	0	14.42	29-09-2026
9	🧠 Великий жор ОЗУ: от космических свердержав до цифрового ожирения ...	0	13.95	28-09-2026

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