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

Дата публикации: 28-09-2026 10:31:33

Каждые 5 минут транзакции в PostgreSQL замирают на 3 - 7 секунд. Разбор кривого механизма сброса WAL на диск.
Если под нагрузкой p99 латентность ваших запросов периодически улетает в космос, а дисковая подсистема в `iostat` рисует адские пики `util` до 100% с провалом пропускной способности, проблема не в ленивых индексах и не в плохих блокировках. Виновник - дефолтный планировщик чекпоинтов в PostgreSQL.
Механизм работает следующим образом. По умолчанию параметр `max_wal_size` выставлен в скромные 1 GB. Как только объем записанных WAL логов достигает этого лимитa или истекает интервал `checkpoint_timeout` (по умолчанию 5 минут), запускается checkpoint. PostgreSQL начинает сбрасывать все накопившиеся грязные страницы (dirty pages) из оперативной памяти на дисковые накопители.
Главная беда кроется в параметре `checkpoint_completion_target`. По умолчанию он равен 0.5. Это значит, что ядро базы пытается сбросить весь объем грязных страниц ровно за половину времени от отведенного интервала. При дефолтном таймауте в 5 минут чекпоинт обязаны завершить за 2.5 минуты. Но реальный объем накопившегося кэша часто таков, что дисковый массив захлебывается в синхронных операциях `fsync`. Контроллер упирается в IOPS, бэкграунд-воркеры забивают очередь записи, и процесс упирается в жесткий троттлинг. База данных просто останавливает выдачу ответов клиентам, пока накопившиеся буферы не запишутся на физический носитель. На графиках мониторинга это выглядит как классические микрофризы длительностью от 3 до 7 секунд.
Решаем проблему на уровне конфигурации и тюнинга ядра Linux.
1. Увеличиваем размер WAL сегментов и отодвигаем порог срабатывания. В `postgresql.conf` выставляем `max_wal_size = 64GB` и `min_wal_size = 4GB`. Это позволяет размазать накопление грязных страниц по времени, снизив пирсинг дисковой подсистемы.
2. Размазываем сброс во времени. Меняем `checkpoint_completion_target = 0.9`. Теперь PostgreSQL будет плавно и равномерно размазывать запись 90% времени от интервала `checkpoint_timeout`, не устраивая дисковый шторм в конце периода.
3. Укрощаем операционную систему. По умолчанию Linux пытается сбросить грязные страницы через `pdflush`/`flusher` потоки агрессивными пачками. Правим параметры в `/etc/sysctl.conf`:
- `vm.dirty_background_ratio = 5` (начинаем фоновый сброс при заполнении 5% RAM, а не ждем дефолтных 10-20%).
- `vm.dirty_ratio = 10` (жесткий стоп для процессов, пишущих на диск, чтобы они не забивали всю память).
- `vm.dirty_expire_centisecs = 3000` (страницы дольше живут в кэше перед принудительным сбросом ядром).
Такой комплексный тюнинг убирает микрофризы и выравнивает утилизацию дисков в ровную линию без деградации p99.
- Инфраструктурный аудит и калькулятор TCO кластера: @Personnel_run_bot (/tma)
- База знаний и разборы: ftops.space
- ftops.space | Run-As-Daemon Infrastructure

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

#	Наименование новости	Тональность	Информативность	Дата публикации
1	Каждые пять минут нагруженный PostgreSQL кластер словно падает в обморок ...	0	7.98	28-09-2026
2	Каждые 5 минут транзакции в PostgreSQL замирают на 3-7 секунд. ...	0	11.43	28-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	Running OpenBao on Kubernetes with a CloudNativePG PostgreSQL backend	0	10.75	16-09-2026
8	🧠 Великий жор ОЗУ: от космических свердержав до цифрового ожирения ...	0	13.95	28-09-2026
9	Recovering a Morpheus Appliance from MySQL InnoDB Corruption	0	7.64	26-09-2026
10	New Patch Series Working Toward DRBD 9 Support In The Linux Kernel	0	7.9	27-09-2026

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