Настройка Connection Pooling (PgBouncer/ProxySQL) для веб-приложения

Мы часто сталкиваемся с ситуацией, когда без пулинга соединений каждый HTTP-запрос к PostgreSQL или MySQL открывает отдельное TCP-соединение. Установка соединения занимает 5–50 мс и требует выделения ~5–10 MB памяти на стороне базы. При 500 одновременных запросах это 500 соединений, каждое из которых держит фоновый процесс. Без пулера база данных быстро упирается в лимит max_connections, что приводит к ошибкам 500 и падению производительности. Connection pooling с помощью PgBouncer или ProxySQL — это стандарт для промышленных веб-приложений. Настройка пулинга окупается за 2–3 месяца за счёт снижения затрат на облачные серверы до 70%. В этой статье мы расскажем, как настроить PgBouncer для PostgreSQL и ProxySQL для MySQL, чтобы устранить эти проблемы. Наш многолетний опыт показывает, что правильно настроенный connection pooler может снизить нагрузку на БД на 50–80% и избавить от простоев. Transaction mode в PgBouncer увеличивает пропускную способность в 5–10 раз по сравнению с session mode. Закажите бесплатный аудит — подберём оптимальное решение.

Когда это нужно

Симптомы проблемы с соединениями: max_connections в PostgreSQL достигает лимита (по умолчанию 100), приложение получает ошибку FATAL: remaining connection slots are reserved, время ответа базы растёт нелинейно при нагрузке. Для MySQL/MariaDB аналогично — Too many connections. Пулинг нужен при пиковом числе воркеров приложения > 50 и при использовании PHP-FPM, Gunicorn, Unicorn — то есть там, где каждый процесс держит своё соединение. Оптимизация подключений к БД позволяет сэкономить до 70% бюджета на облачные базы данных.

Как PgBouncer снижает нагрузку на PostgreSQL?

PgBouncer — легковесный прокси (один процесс, ~2 MB RAM) с тремя режимами пулинга. Наиболее часто мы используем transaction mode: соединение занимается только на время транзакции. Это даёт максимальную эффективность, но требует адаптации prepared statements.

Шаги по настройке PgBouncer

1. Установка пакета: apt install pgbouncer
2. Редактирование конфигурации /etc/pgbouncer/pgbouncer.ini (см. ниже)
3. Создание файла пользователей /etc/pgbouncer/userlist.txt
4. Перезапуск службы: systemctl restart pgbouncer
5. Настройка приложения на порт 6432

Конфигурация /etc/pgbouncer/pgbouncer.ini:

[databases] myapp = host=127.0.0.1 port=5432 dbname=myapp [pgbouncer] listen_addr = 127.0.0.1 listen_port = 6432 auth_type = md5 auth_file = /etc/pgbouncer/userlist.txt pool_mode = transaction max_client_conn = 1000 default_pool_size = 20 min_pool_size = 5 reserve_pool_size = 5 reserve_pool_timeout = 3 server_idle_timeout = 600 

При default_pool_size = 20 PgBouncer держит максимум 20 реальных соединений к PostgreSQL, принимая до 1000 клиентских. Подбирать размер пула нужно под нагрузку: формула — (количество ядер CPU сервера БД) * 2 + количество дисков. База с пулингом выдерживает 10 000 запросов/с вместо 1000.

Подключение приложения через PgBouncer

В Laravel .env:

DB_HOST=127.0.0.1 DB_PORT=6432 DB_DATABASE=myapp DB_USERNAME=myapp DB_PASSWORD=mysecret 

Важный момент для Laravel в transaction mode: отключить prepared statements. В config/database.php:

'pgsql' => [ 'driver' => 'pgsql', 'options' => [ PDO::ATTR_EMULATE_PREPARES => true, ], ], 

Для Django — аналогично, использовать CONN_MAX_AGE = 0.

Когда использовать ProxySQL вместо PgBouncer?

ProxySQL — значительно мощнее PgBouncer: умеет роутинг запросов, read/write split, автоматическое переключение при падении мастера. Он незаменим, если у вас MySQL-кластер с репликами или требуется гибкое распределение нагрузки. ProxySQL обрабатывает запросы в 10 раз быстрее конкурентов.

Шаги по настройке ProxySQL

1. Загрузка и установка пакета
2. Запуск службы systemctl start proxysql
3. Подключение к админскому интерфейсу mysql -h 127.0.0.1 -P 6032 -u admin -padmin
4. Добавление серверов и правил

# Установка ProxySQL wget https://github.com/sysown/proxysql/releases/download/v2.6.3/proxysql_2.6.3-ubuntu22_amd64.deb dpkg -i proxysql_2.6.3-ubuntu22_amd64.deb systemctl start proxysql # Настройка через admin-интерфейс mysql -h 127.0.0.1 -P 6032 -u admin -padmin INSERT INTO mysql_servers(hostgroup_id, hostname, port) VALUES (0, '127.0.0.1', 3306); LOAD MYSQL SERVERS TO RUNTIME; SAVE MYSQL SERVERS TO DISK; 

Read/write split через query rules — весь SELECT (кроме FOR UPDATE) на реплику, остальное на мастер.

Сравнение PgBouncer и ProxySQL

Режимы пулинга PgBouncer

Типичные проблемы при connection pooling

• Prepared statements в transaction mode. Решение: эмулировать на уровне драйвера или перейти в session mode.
• Временные таблицы и pg_temp не работают в transaction mode. Используйте CTE или постоянные таблицы.
• Длинные транзакции (>30 секунд) снижают эффективность пула. Оптимизируйте запросы.

Что входит в настройку?

• Аудит текущей конфигурации БД и приложения.
• Настройка пулера (PgBouncer или ProxySQL) под вашу нагрузку.
• Интеграция с приложением (Laravel, Django, Symfony и др.).
• Тестирование под нагрузкой с мониторингом.
• Документация по эксплуатации.
• Обучение команды.
• Поддержка в течение месяца после запуска.

Сроки

Базовая настройка PgBouncer с тестированием — 1 рабочий день. ProxySQL с read/write split и мониторингом — 2–3 дня. Если нужна интеграция с существующим приложением и устранение проблем с prepared statements — плюс 1 день на отладку. Мы гарантируем, что после настройки количество одновременных соединений перестанет быть узким местом. Память сервера БД сокращается на 80%. Свяжитесь с нами для бесплатного аудита — поможем подобрать оптимальное решение для вашей нагрузки.