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

Команда добавляет PgBouncer и устанавливает pool_size = 200 — по числу клиентов. P99 не падает, а растёт. Добавление backend’ов к Postgres сделало всё медленнее. Формула размера пула — не «одно соединение на клиента».

Почему больше 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:

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 с для быстрого отказа).