Пул соединений (connection pool) — промежуточный слой между приложением и базой данных, хранящий набор уже установленных соединений. Когда приложению нужно выполнить запрос, оно берёт соединение из пула (занимает его), выполняет запрос и возвращает соединение обратно в пул — без разрыва TCP-соединения с БД. Это устраняет задержку на создание нового соединения (TCP-рукопожатие, аутентификация, инициализация сессии), которая для PostgreSQL составляет 3–10 мс, а накопленная по тысячам запросов — секунды.
Как работает
При старте пул создаёт заданное количество соединений (min_pool_size) и держит их открытыми. Каждое соединение с PostgreSQL потребляет около 1,3–5 МБ памяти на стороне сервера БД (postmaster порождает отдельный процесс per connection). При 1000 одновременных соединений PostgreSQL без пулера расходует 1,3–5 ГБ RAM только на обслуживание соединений, ещё до выполнения запросов.
Пулер принимает подключения от приложения (frontend соединения) и мультиплексирует их в меньший набор реальных соединений с БД (backend соединения). Соотношение 100:1 и выше — типичная конфигурация: 1000 клиентских соединений обслуживают 10–20 backend соединений.
Режимы работы пулера (на примере pgBouncer):
- Session mode
- Один клиент — одно backend-соединение на всё время сессии. Минимальное мультиплексирование, но максимальная совместимость.
- Transaction mode
- Backend-соединение выделяется только на время транзакции. После завершения транзакции соединение возвращается в пул. Наиболее эффективный режим для OLTP.
- Statement mode
- Соединение выделяется на один запрос. Не совместим с multi-statement транзакциями.
Популярные реализации: pgBouncer (PostgreSQL, lightweight, C), Pgpool-II (PostgreSQL, с балансировкой и failover), ProxySQL (MySQL/MariaDB, с маршрутизацией запросов), HikariCP (Java, встроенный пул для JDBC).
История
Концепция connection pool появилась в 1990-х годах вместе с ростом веб-трафика. Первые серверы приложений (WebLogic, JBoss) в 1999–2001 годах включали пулы соединений как встроенную функцию. pgBouncer разработан Skype в 2007 году для масштабирования PostgreSQL под миллионы пользователей. HikariCP (2013) стал стандартом для Java-приложений благодаря минимальным накладным расходам. Managed connection pooling от облачных провайдеров (DigitalOcean Managed Databases, Supabase) сделал пулер прозрачной инфраструктурой.
На что обращать внимание
Правильный max_pool_size зависит от числа ядер CPU сервера БД и типа нагрузки. Для OLTP-нагрузки оптимально: max_pool_size = (число_ядер * 2) + количество_дисков — правило «pool size = cores * 2» для PostgreSQL. Слишком большой пул не улучшает производительность — БД не может параллельно выполнить больше запросов, чем имеет CPU.
Для VPS с Galera Cluster или PostgreSQL используйте pgBouncer в transaction mode: он снижает нагрузку на БД и позволяет обрабатывать тысячи одновременных запросов на сервере с 16–32 backend-соединениями. Мониторинг: SHOW POOLS в pgBouncer показывает число активных, ожидающих и свободных соединений в реальном времени.
Принцип работы connection pool
Создание TCP-соединения к БД занимает 5–50 мс. Pool поддерживает N открытых соединений, переиспользует их. Запрос берёт свободное соединение из pool, использует, возвращает. Без pool при 1000 RPS = 1000 соединений в секунду к БД — PostgreSQL не выдержит.
Размер пула
Правило для PostgreSQL: pool_size = (2 × число_CPU_ядер + эффективные_диски). Например, 4 ядра + 2 NVMe = 10 соединений. Слишком большой пул не улучшает производительность: PostgreSQL с 200 активными соединениями медленнее, чем с 20. PgBouncer для PostgreSQL — внешний пул-менеджер.
Pool в разных технологиях
Python/SQLAlchemy: pool_size=10, max_overflow=20. Node.js/pg: max: 10. Java/HikariCP: maximumPoolSize=10. Redis тоже имеет пул соединений. PgBouncer режимы: session (1 соединение на сессию), transaction (наиболее эффективный), statement.
Пул соединений необходим для PostgreSQL (PgBouncer) и MySQL. В Docker: каждый контейнер использует свой пул. Redis имеет собственный пул соединений. Nginx keepalive для upstream — аналог пула. Kubernetes: пул соединений на уровне приложения, не инфраструктуры.