Размер пула: формула (ядра × 2) + шпинделей и двухуровневый стек

Почему больше Postgres backend’ов не означает больше пропускной способности

Каждый Postgres backend — это отдельный OS-процесс. После нескольких кратного числа ядер CPU дополнительные активные backend’ы перестают давать прирост пропускной способности и начинают её снижать: больше переключений контекста, больше конкуренции за общие структуры памяти (proc array при снятии снапшота, таблица блокировок), больше накладных расходов ядра на планирование.

Формула, популяризированная HikariCP, для оптимального числа активных backend’ов на стороне Postgres:

pool_size = (ядра CPU × 2) + effective_spindle_count

• ядра × 2 покрывает CPU-параллелизм и часть эффекта hyper-threading
• effective_spindle_count добавляет запас для I/O-параллелизма, когда хранилище может обслуживать несколько параллельных чтений

На современных NVMe при хорошо прогретом кэше число шпинделей фактически равно 0 — формула сводится к ядра × 2. На 16-ядерном Postgres-сервере с данными в RAM: pool_size ≈ 32, а не 200.

Это pool_size (или default_pool_size) в PgBouncer, а не число воркеров приложения.

Размер клиентского пула на воркер

Клиентский пул (node-postgres, HikariCP, asyncpg) размеряется иначе — по внутреннему параллелизму воркера, а не по числу ядер Postgres. Когда видишь медленный API и замечаешь, что каждый запрос ждёт checkout из пула, формула ниже даёт точный ответ, сколько соединений нужно этому воркеру:

worker_pool_size ≈ concurrent_requests × db_calls_per_request × avg_query_ms / request_budget_ms

Пример: 100 параллельных запросов на воркер, 2 вызова БД по 5 мс, бюджет запроса 50 мс:

= 100 × 2 × 5 / 50 = 20 соединений

При 10 воркерах: 200 клиентских соединений к PgBouncer — дёшево (~2 КБ на соединение). PgBouncer мультиплексирует их на пул из ~24 backend’ов.

Конкретный пример расчёта пула

Ключевые параметры PgBouncer

pool_size (целевой размер backend-пула на БД, по умолчанию 20) — устанавливайте в (ядра × 2) + шпиндели + ~50% запас. Это потолок реальных Postgres backend’ов, которые поддерживает PgBouncer.

reserve_pool_size — дополнительные backend’ы, которые PgBouncer может поднять под пиковую нагрузку (по умолчанию 0; устанавливайте ~25% от pool_size).

max_client_conn — максимальное число входящих клиентских соединений PgBouncer (по умолчанию 100; устанавливайте в тысячи — клиентские соединения дёшевы).

server_reset_query = DISCARD ALL — SQL, выполняемый против backend’а перед возвратом в пул; очищает утёкшее состояние сессии.

query_wait_timeout — сколько клиент может ждать backend’а перед отклонением (по умолчанию 120 с; в production: 10–30 с для быстрого отказа).

Вместе эти пять параметров формируют защитный контур: pool_size управляет нагрузкой на Postgres, reserve_pool_size обрабатывает всплески, max_client_conn защищает сам пулер от перегрузки, server_reset_query предотвращает утечку состояния между клиентами, а query_wait_timeout превращает исчерпание пула в быстрый явный сбой вместо тихой очереди. Пропусти любой — под нагрузкой проявится соответствующий режим отказа.