Каждые пять минут нагруженный PostgreSQL кластер словно падает в обморок ...

Дата публикации: 27-09-2026 00:18:07

Каждые пять минут нагруженный PostgreSQL кластер словно падает в обморок - транзакции замирают на три-семь секунд, соединения висят на пуле, а p99 latency улетает в космос. Причина кроется в дефолтных настройках механизма checkpoint, которые гарантируют классический IO-шторм.
По умолчанию параметр max_wal_size установлен на скромные 1 GB. Как только объем измененных данных в WAL достигает этого лимитa - или истекает таймаут checkpoint_timeout в пять минут, - ядро СУБД обязано сбросить все грязные страницы памяти на дисковый массив. PostgreSQL включает режим агрессивного сброса, пытаясь записать гигабайты накопившихся dirty pages за минимальное время.
Дисковая подсистема захлебывается. Очередь записи в OS page cache переполняется, пропускная способность контроллера упирается в hardware-лимит, и даже простые фоновые SELECT-запросы начинают ждать блокировки на чтение буферов. Storage выдает 100% utilisation, IOPS падает в ноль, а мониторинг фиксирует синхронный всплеск системного CPU в состоянии iowait.
Чтобы база данных перестала устраивать микрофризы, этот объем работы нужно плавно размазать во времени. Наша цель - заставить чеклинеры работать постоянно и незаметно, избегая пиковых нагрузок на диски.
Первым делом увеличиваем пул WAL-файлов. Установка max_wal_size в 16 GB или 32 GB дает буферу удержать больше изменений без аварийного триггера. Min_wal_size поднимаем до 2-4 GB, чтобы PostgreSQL не занимался постоянным пересозданием файлов в тихие периоды.
Второй шаг - растягиваем интервал самого checkpoint_timeout до 30 или 60 минут. Больше окно означает, что те же 16 гигабайт изменений будут сбрасываться не за пять минут, а за полчаса.
Третий и главный инструмент - параметр checkpoint_completion_target. По умолчанию он равен 0.9, что означает попытку завершить сброс за 90% от отведенного времени. Для высоконагруженных систем выставляем его в 0.95 или даже 0.98. Это заставляет фоновый процесс bgwriter и чеклинеры писать данные на диск микропорциями, строго дозирая IOPS.
Дополнительно тюним бэкграунд-писатель: увеличиваем bgwriter_lru_maxpages до 200-400 и снижаем bgwriter_lru_multiplier до 2.0-3.0. Это гарантирует, что страницы вымываются из памяти заранее, во время обычной работы транзакций, а не в момент срабатывания чеклиста.
В результате диск переходит из режима удушья в фоновый рабочий ритм, p99 задержки выравниваются, а пользователи перестают замечать техническое обслуживание СУБД.
- Инфраструктурный аудит и калькулятор TCO кластера: @Personnel_run_bot (/tma)
- База знаний и разборы: ftops.space
- ftops.space | Run-As-Daemon Infrastructure

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

#	Наименование новости	Тональность	Информативность	Дата публикации
1	База данных захлебывается в дисковом I/O wait, хотя на сервере ...	0	8.6	26-09-2026
2	База данных захлебывается в дисковом I/O wait, хотя на сервере ...	0	8.41	26-09-2026
3	Доверить сервер ИИ-агенту и не пожалеть: как спать спокойно без SSH	0	12.58	26-09-2026
4	[Голос Стаи: Архитектор Сети] Вам продают "удобство облака", но на ...	0	7.7	26-09-2026
5	Pony ORM: толстая пачка фич и улучшений	0	9.58	26-09-2026
6	xk6-sip: мониторинг нагрузочного тестирования VoIP/SIP-звонков	0	17.21	26-09-2026
7	Какие наши продукты задевает эта CVE? Я продолжил заброшенный Minefield и нашёл, что он читал SBOM задом наперёд	0	9	26-09-2026
8	Ну что, народ, эпохальный апгрейд официально завершен! Наконец-то полностью перетряхнул ...	0	11.9	26-09-2026
9	Событие вместо поля: как журнал медиации вернул историю, которую система стирала	0	7.62	26-09-2026
10	10.000 PDFs? Stirling PDF macht daraus einen Job	0	17.14	25-09-2026

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