Как установить и настроить pgBouncer на VPS

MAATRIX

pgBouncer на VPS решает одну из самых частых проблем нагруженных приложений на PostgreSQL — слишком много соединений. Каждое подключение к PostgreSQL стоит памяти, и когда клиентов сотни, база задыхается. pgBouncer встаёт лёгким прокси между приложением и базой: держит небольшой пул реальных соединений и мультиплексирует между ними тысячи клиентских. Ниже — рабочий путь: установка, настройка пула, выбор режима пулинга, авторизация и подключение приложения.

Зачем нужен pgBouncer

PostgreSQL создаёт под каждое соединение отдельный процесс, и это дорого: несколько мегабайт памяти на коннект плюс накладные расходы. При 500 подключениях уходят гигабайты RAM только на обслуживание соединений, даже если большинство из них простаивает. А приложения, особенно на PHP или в serverless-стиле, открывают и закрывают соединения постоянно, и установка нового коннекта — сама по себе недешёвая операция.

pgBouncer решает это элегантно. Он держит, скажем, 20 реальных соединений к PostgreSQL и отдаёт их клиентам по мере надобности. Приложение думает, что у него сотни коннектов, а база обслуживает два десятка и работает спокойно. В результате вы либо снимаете упор в лимит max_connections, либо экономите память под другие задачи, либо ускоряете короткие запросы за счёт переиспользования готовых соединений. Это одна из самых дешёвых и эффективных оптимизаций для нагруженной базы.

pgBouncer нетребователен — он однопоточный, лёгкий и работает даже на самом скромном VPS рядом с базой или приложением. Держат его обычно на том же сервере, что и PostgreSQL, или на сервере приложения.

Установка pgBouncer

pgBouncer есть в штатном репозитории Ubuntu, установка простая:

sudo apt update
sudo apt install -y pgbouncer

Основные файлы: конфиг /etc/pgbouncer/pgbouncer.ini и файл авторизации /etc/pgbouncer/userlist.txt. Служба управляется через systemd. После установки pgBouncer по умолчанию слушает порт 6432 — приложение будет подключаться к нему вместо стандартного 5432 PostgreSQL. Проверьте, что пакет встал и служба видна:

sudo systemctl status pgbouncer

Сам PostgreSQL при этом продолжает слушать 5432, а pgBouncer становится посредником на 6432. Такое разделение портов удобно: вы всегда понимаете, идёт ли подключение напрямую к базе или через пул.

Настройка пула соединений

Откройте главный конфиг и опишите, к какой базе проксировать и с какими параметрами пула:

sudo nano /etc/pgbouncer/pgbouncer.ini

[databases]
appdb = host=127.0.0.1 port=5432 dbname=appdb

[pgbouncer]
listen_addr = 127.0.0.1
listen_port = 6432
auth_type = scram-sha-256
auth_file = /etc/pgbouncer/userlist.txt
pool_mode = transaction
max_client_conn = 1000
default_pool_size = 20

Разберём ключевое. Секция [databases] описывает, куда проксировать: клиент, подключившийся к pgBouncer с базой appdb, попадёт на реальный PostgreSQL. max_client_conn — сколько клиентов pgBouncer готов принять (тысяча). default_pool_size — сколько реальных соединений к PostgreSQL он под них держит (двадцать). Именно это соотношение и даёт эффект: тысяча клиентов обслуживается двадцатью коннектами к базе. Значение default_pool_size подбирают экспериментально — обычно достаточно небольшого числа, потому что запросы короткие и соединения быстро освобождаются. Важно держать в голове арифметику: суммарное число серверных соединений, которые может открыть pgBouncer по всем базам и пользователям, не должно превышать max_connections самой PostgreSQL с запасом. Иначе вы просто перенесёте проблему нехватки коннектов с уровня приложения на уровень базы. Есть отдельный параметр reserve_pool_size — небольшой резерв соединений, который включается, когда основной пул исчерпан и клиенты начинают ждать дольше заданного порога; он сглаживает короткие всплески нагрузки, не раздувая пул постоянно.

Выбор режима пулинга

Параметр pool_mode — самое важное решение, и от него зависит совместимость с приложением. Есть три режима. session — соединение отдаётся клиенту на всю его сессию и возвращается в пул только при отключении; самый безопасный, но наименее эффективный, фактически близок к обычному подключению. transaction — соединение отдаётся на время одной транзакции и сразу возвращается в пул; оптимальный баланс для веб-приложений, даёт максимальный выигрыш. statement — возврат после каждого запроса, самый агрессивный, подходит для специфичных случаев.

Для большинства проектов правильный выбор — transaction. Но есть важная оговорка: в этом режиме нельзя использовать вещи, живущие дольше транзакции, — подготовленные выражения на уровне сессии, временные таблицы, SET на сессию, advisory locks. Если приложение или ORM на них полагается, оно может ломаться. Многие драйверы имеют режим совместимости с transaction pooling — включите его. Если приложение активно использует сессионные фичи и не умеет их отключать, оставайтесь на session. Понимание этого компромисса избавит вас от загадочных ошибок в продакшене.

Авторизация

pgBouncer проверяет пароль клиента по файлу userlist.txt, где хранятся имя пользователя и хеш пароля. Добавьте туда пользователей, которые будут ходить через пул:

sudo nano /etc/pgbouncer/userlist.txt

"appuser" "SCRAM-SHA-256$4096:..."

Хеш пароля можно взять прямо из PostgreSQL — он хранится в системной таблице pg_shadow. Это удобно: пароли не дублируются в открытом виде. После настройки перезапустите pgBouncer и проверьте подключение через него:

sudo systemctl restart pgbouncer
psql -h 127.0.0.1 -p 6432 -U appuser -d appdb

Если вошли — пул работает. Обратите внимание: подключение идёт на порт 6432, а не 5432. У pgBouncer есть и служебная административная консоль — подключившись к специальной базе pgbouncer, вы можете смотреть статистику пулов командой SHOW POOLS и число клиентов через SHOW CLIENTS.

Подключение приложения и проверка

Последний шаг — переключить приложение с прямого подключения к PostgreSQL на pgBouncer. В строке подключения поменяйте порт с 5432 на 6432, остальное остаётся тем же. Приложение даже не заметит разницы, а база получит разгрузку. Проверяйте эффект через административную консоль pgBouncer: команда SHOW POOLS покажет, сколько клиентов подключено и сколько реальных серверных соединений используется — вы увидите, как сотни клиентов обслуживаются десятком коннектов.

pgBouncer особенно ценен, когда база и приложение живут на разных серверах или когда фронтендов несколько. Чтобы схема работала стабильно, нужен надёжный VPS рядом с базой. В MAATRIX можно арендовать серверы под PostgreSQL и pgBouncer в России, США или Великобритании и оплатить картой РФ, по СБП, криптой или токеном MAAT — иностранная карта не нужна.

Частые вопросы