Процессная модель Postgres и почему увеличение max_connections снижает производительность

Команда сталкивается с исчерпанием пула. Они поднимают max_connections со 100 до 1000. P99 ухудшается. Поднимают до 2000. База данных начинает падать с OOM. Повышение max_connections — это инстинкт; понимание того, почему это не работает, — это навык.

Процессная модель Postgres подробно

При подключении клиента postmaster (процесс-супервизор) форкает новый backend-процесс. Каждый backend имеет:

• Приватная память: ~5–10 МБ резидентной памяти (рабочая память для запросов, кэш планов, буферы libpq). На 16-ядерной машине с 1 000 backend’ов это ~5–10 ГБ только для приватной памяти backend’ов.
• Слот в общей памяти: запись proc array (снятие снапшота сканирует её), запись в таблице блокировок, метаданные predicate-lock. Эти структуры предварительно выделяются при запуске, размером под max_connections. Удвоение max_connections удваивает фиксированный объём общей памяти.
• Ядерный процесс с собственным стеком, таблицей файловых дескрипторов и записью в планировщике.

Запуск соединения стоит ~5 мс на стороне Postgres (fork + инициализация) плюс TLS и аутентификация на сетевой стороне.

Почему процессы, а не потоки? Postgres появился раньше надёжного pthreads на большинстве Unix-вариантов. Процессная модель даёт изоляцию сбоев (OOM одного backend не портит общую память), простое управление приватной кучей и лёгкое форкание воркеров параллельных запросов. Ценой является нередуцируемые накладные расходы на соединение — которые поглощает пулинг.

Почему увеличение max_connections снижает пропускную способность

Наивные команды поднимают max_connections со 100 до 1 000 при исчерпании пула. Четыре вещи идут не так:

1. Масштабирование общей памяти: max_connections = 1000 предварительно выделяет ~500 МБ+ фиксированной общей памяти только для proc array, хэша блокировок и структур predicate-lock — ощутимо на небольших инстанциях.

2. Накладные расходы переключения контекста: при 1 000 активных backend’ов под нагрузкой время планирования ядра становится измеримой долей CPU. Каждый OS-процесс конкурирует за планировщик.

3. Конкуренция на менеджере блокировок: итерация proc array при снятии снапшота O(active_backends). При 1 000 активных backend’ов каждый BEGIN сканирует 1 000 записей. Сканы таблицы блокировок и конкуренция за MultiXact буфер масштабируются аналогично.

4. Очередь форка postmaster: создание соединения требует форка нового процесса через postmaster; при высокой частоте соединений это сериализуется. ~2 КБ PgBouncer на клиентское соединение против ~10 МБ Postgres на backend — ключевая асимметрия.

Кривая пропускной способности нелинейна: 16-ядерный Postgres достигает пика примерно при 32–48 активных backend’ах и деградирует после него. Добавление backend’ов после пика означает, что каждый backend получает меньшую долю CPU, при этом платя за бо́льшие накладные расходы конкуренции.

Практический лимит max_connections

Руководство сообщества Postgres (неизменное 25+ лет): ограничьте max_connections несколькими сотнями. Практический диапазон для production OLTP — 200–500: достаточно для административных соединений, реплик и некоторого запаса выше pool_size пулера.

Распределение бюджета max_connections:

• PgBouncer pool_size (primary) + reserve_pool_size — реальные OLTP backend’ы
• Соединения реплик (потоковая репликация)
• superuser_reserved_connections (по умолчанию 3) — для аварийного доступа
• Административные и мониторинговые соединения
• Пулы PgBouncer для read-реплик, если есть

Пример: 8-ядерный primary, pool_size = 24, reserve = 6, 2 реплики по pool_size = 20, superuser_reserved = 3, admin/monitoring = 10. Итого: 24 + 6 + 40 + 3 + 10 = 83. max_connections = 100 — нормально; max_connections = 1000 — расточительно и вредно.