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

Дата публикации: 24-09-2026 05:14:23

Каждые 5 минут транзакции в PostgreSQL замирают на 3 - 7 секунд. Разбор кривого механизма сброса WAL на диск.
В высоконагруженных инсталляциях PostgreSQL периодические затыки на несколько секунд - классическая боль. Метрики зашкаливают, p99 улетает в космос, а мониторинг показывает идеальную картину по CPU. Корень зла кроется в дефолтных настройках подсистемы checkpoint и том, как ядро Linux работает с грязными страницами.
По умолчанию параметр `max_wal_size` выставлен в скромные 1 GB, а `checkpoint_completion_target` равен 0.5. Это значит, что процесс checkpointer обязан сбросить весь накопленный объем из Shared Buffers на накопитель ровно за половину времени от генерации этого объема WAL. При интенсивной записи в 500 MB/s гигабайт WAL улетает за пару секунд. Checkpointer в панике начинает молотить дисковую подсистему на максимальных оборотах, упираясь в лимиты IOPS и пропускную способность NVMe или RAID-контроллера.
Ситуацию усугубляет поведение планировщика ввода-вывода Linux. Когда грязные страницы лавинообразно сбрасываются через системные вызовы `fsync()` или фоновые воркеры `pdflush`/`dirtywriteback`, кэш страниц переполняется. Ядро внезапно переходит в режим synchronous throttle, заставляя процессы записи блокироваться в ожидании освобождения буферов. База данных физически не может принять новые транзакции, пока дисковый подсистема не переварит этот шторм.
Решением проблемы становится агрессивное размазывание нагрузки. Первое действие - поднятие `max_wal_size` до 16 GB - 64 GB в зависимости от объема RAM и интенсивности транзакций. Больший размер окна позволяет растянуть процесс сброса грязных страниц во времени. Второе действие - изменение `checkpoint_completion_target` на 0.9. Это заставит checkpointer плавно расходовать 90% времени интервала между чейкпоинтами, а не устраивать дисковый апокалипсис в первые же секунды.
Дополнительно на уровне ОС необходимо тюнить параметры ядра через `sysctl`. Выставление `vm.dirty_background_ratio` на уровне 5 - 10 и `vm.dirty_ratio` на уровне 20 - 30 предотвращает резкое накопление грязных страниц в памяти, заставляя Linux фоново сбрасывать их на диск мелкими порциями. В связке с планировщиком `mq-deadline` или `none` для NVMe это полностью убивает микрофризы и стабилизирует латентность базы.
- Инфраструктурный аудит и калькулятор TCO кластера: @Personnel_run_bot (/tma)
- База знаний и разборы: ftops.space
- ftops.space | Run-As-Daemon Infrastructure

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

#	Наименование новости	Тональность	Информативность	Дата публикации
1	Каждые 5 минут транзакции в PostgreSQL замирают на 3 - ...	0	11.17	21-09-2026
2	Каждые 5 минут транзакции в PostgreSQL замирают на 3 - ...	0	9.34	22-09-2026
3	PostgreSQL Autovacuum Internals and Benchmark	0	4.74	01-07-2026
4	The insert benchmark on a small server : Postgres 12.22 through 18.3	0	11.9	29-03-2026
5	Fixing Common PostgreSQL Performance Bottlenecks	0	5.59	04-12-2020
6	[Перевод] Статистика PostgreSQL: почему запросы выполняются медленно	0	7.74	19-08-2026
7	The Real Operational Cost of Vacuuming in PostgreSQL	0	10.7	08-02-2026
8	Асинхронный I/O в PostgreSQL или история выходного дня	0	9.78	17-08-2026
9	PostgreSQL для бэкендера: 10 фич, которыми мало пользуются, а зря	5	7	30-06-2026
10	serversetup - external edit	0	17.7	24-09-2026

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