Connection Pooling
Тема дорожной карты · PostgreSQL
Пул соединений — критически важный инструмент масштабирования для развёртываний PostgreSQL, поскольку каждый серверный процесс PostgreSQL потребляет значительный объём памяти — как правило, 5–10 МБ — и реляционная база данных может стать узким местом, когда сотни потоков приложения удерживают прямые соединения. Параметр max_connections в postgresql.conf устанавливает жёсткий предел одновременных соединений, и при его превышении новые попытки подключения немедленно завершаются ошибкой «too many clients». PgBouncer является наиболее широко используемым пулером соединений для PostgreSQL; по умолчанию он работает в режиме пула транзакций, мультиплексируя множество клиентских соединений на значительно меньшее число серверных и существенно сокращая накладные расходы на установку соединений в высоконагруженных OLTP-системах. Правильный подбор размера пула — как правило, max_connections устанавливается в 100–200 на стороне PostgreSQL, а pool_size в PgBouncer настраивается согласно числу ядер CPU — является основополагающим шагом в оптимизации запросов PostgreSQL и разработке производительных систем.
Как это работает
Connection Pooling мультиплексирует много app-уровневых соединений на несколько реальных Postgres-backend. Каждое соединение Postgres ест ~10MB RAM + backend-процесс; тысячи idle app-соединений вычерпывают сервер. PgBouncer (transaction-level pooling — дефолт и самый полезный) и PgCat — стандартные инструменты. App-уровневые пулы (HikariCP, pg-pool) держат сторону приложения. Комбинируйте оба слоя в серьёзном production.
Когда применять
PgBouncer — когда app pod × размер пула > max_connections Postgres. transaction-режим по дефолту; session — если приложение использует prepared statements, advisory lock или session GUC, которые должны жить. App-side pool — ~10-20 на worker; PgBouncer гасит всплески. Тестируйте pgbench -c <ожидаемая конкурентность> до запуска.
Типичные ошибки
Ловушки Connection Pooling: забыли, что transaction-режим ломает prepared statements (PG 14+ имеет server-side cache, но проверьте драйвер); PgBouncer один поток на гигантском боксе (не масштабирует 32 ядра — несколько процессов или PgCat); нет мониторинга pool wait time (клиенты тихо блокируются на полном пуле). Читайте SHOW STATS PgBouncer.