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

Дата публикации: 25-09-2026 01:55:47

Каждые 5 минут транзакции в PostgreSQL замирают на 3 - 7 секунд - не по вине сети или дисков, а из - за встроенного механизма checkpoint_completion_target. По умолчанию в конфигурации PostgreSQL стоит значение 0.5. Это значит, что база данных пытается сбросить весь накопленный объем грязных страниц (dirty pages) из оперативной памяти на диск ровно за половину времени от расписания чекпоинтов.
При дефолтном лимите max_wal_size в 1 гигабайт чекпоинты триггерятся каждые несколько минут под нагрузкой. PostgreSQL сжигает всю доступную пропускную способность дисковой подсистемы (IOPS) за короткое окно времени. Ядро Linux захлебывается в системных вызовах fsync() и выстраивает тяжелую очередь в page cache. В этот момент замирают абсолютно все запросы - пулы соединений исчерпываются, а latency p99 улетает в космос.
Проблема кроется в неравномерности распределения дисковой нагрузки. Когда checkpoint_completion_target равен 0.5, система отдыхает первую половину интервала, а во вторую - на максимальных оборотах переносит гигабайты грязных страниц на накопители. На высоконагруженных инстансах с NVMe накопителями это приводит к насыщению очереди SCSI-контроллера и деградации пропускной способности SSD из - за исчерпания внутреннего буфера записи.
Решить проблему микрофризов можно через изменение двух параметров в postgresql.conf. Первый - увеличение max_wal_size до 10 - 32 гигабайт (или даже выше в зависимости от объема памяти и интенсивности транзакций). Это снизит частоту срабатывания чекпоинтов по таймеру заполнения WAL. Второй - поднятие checkpoint_completion_target до значения 0.9 или даже 0.95.
Такая настройка заставляет PostgreSQL распределять сброс грязных страниц равномерно практически по всему интервалу между чекпоинтами. Пиковая нагрузка на дисковую подсистему падает в разы, операционная система успевает синхронизировать блоки фоновыми потоками pdflush / flush, а планировщик ввода - вывода Linux (например, mq-deadline или none для NVMe) работает в штатном режиме без лавинного роста задержек.
Дополнительно на уровне ядра Linux для баз данных критически важно тюнить параметры виртуальной памяти:
- sysctl -w vm.dirty_background_ratio = 5 - ядро начинает фоновый сброс грязных страниц раньше, не дожидаясь критического заполнения RAM.
- sysctl -w vm.dirty_ratio = 10 - жесткий лимит, при котором процессы начинают блокироваться на запись, предотвращая резкий оверфлоу памяти и последующие тяжелые стопы.
- Инфраструктурный аудит и калькулятор TCO кластера: @Personnel_run_bot (/tma)
- База знаний и разборы: ftops.space
- ftops.space | Run-As-Daemon Infrastructure

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

#	Наименование новости	Тональность	Информативность	Дата публикации
1	Каждые 5 минут транзакции в высоконагруженной PostgreSQL базе внезапно замирают ...	0	11.86	24-09-2026
2	Каждые 5 минут транзакции в PostgreSQL замирают на 3 - ...	0	11.17	21-09-2026
3	Каждые 5 минут транзакции в PostgreSQL замирают на 3 - ...	0	9.34	22-09-2026
4	PostgreSQL и временные таблицы. Часть 2: почему 1024 счётчиков бывает мало	0	10.98	09-09-2026
5	База данных захлебывается в дисковом I/O wait, хотя на сервере ...	0	7.98	25-09-2026
6	Записки оптимизатора 1С (ч.19). Как настройка Huge Pages в Linux влияет на устойчивость работы Postgres	0	7.86	04-09-2026
7	Fixing Common PostgreSQL Performance Bottlenecks	0	5.59	04-12-2020
8	PostgreSQL Autovacuum Internals and Benchmark	0	4.74	01-07-2026
9	The insert benchmark on a small server : Postgres 12.22 through 18.3	0	11.9	29-03-2026
10	[Перевод] Статистика PostgreSQL: почему запросы выполняются медленно	0	7.74	19-08-2026

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