---
title: PGbouncer
description: 
published: true
date: 2023-11-15T17:53:07.867Z
tags: 
editor: markdown
dateCreated: 2023-11-15T17:46:34.218Z
---

Типичные веб-проекты, разрабатываемые на чем-то вроде [_Python_](https://eax.me/python/) или PHP, характерны тем, что создают большое количество соединений к СУБД — по одному, а иногда и по несколько, *на каждый HTTP-запрос*. Имея классическую архитектуру «один процесс на соединение», PostgreSQL не очень хорошо справляется с большим (условно, больше 100) количеством соединений. Решить проблему позволяет пулер соединений под названием [_PgBouncer_](https://pgbouncer.github.io/). Благодаря использованию библиотеки [_libevent_](https://eax.me/libevent/), PgBouncer может поддерживать большое количество (тысячи) соединений, которые проксируются на несколько (пара десятков) соединений непосредственно к PostgreSQL.

Данная заметка предполагает, что на сервере у вас используется Ubuntu Linux, так как сегодня это, по всей видимости, наиболее популярный серверный дистрибутив Linux. Отличия описанный далее шагов для других дистрибутивов будут минимальными. Также предполагается, что на сервере уже установлен PostgreSQL.

Устанавливается PgBouncer очень просто:

```
sudo apt-get install pgbouncer
```

По умолчанию прокси слушает порт 6432. Логи можно почитать так:

```
less /var/log/postgresql/pgbouncer.log
```

Конфигурационный файл называется /etc/pgbouncer/pgbouncer.ini. Рассмотрим основные параметры.

```
;; database name = connect string
;;
;; connect string params:
;;   dbname= host= port= user= password=
;;   client_encoding= datestyle= timezone=
;;   pool_size= connect_query=
;;   auth_user=
[databases]
 
* = host=localhost port=5432
```

Здесь мы можем указать, на каких серверах какие базы нужно искать. Звездочкой обозначается дэфолтный сервер. Кстати, это хоть еще и примитивный, но все-таки уже шардинг.

Не менее важная настройка:

```
; When server connection is released back to pool:
;   session      - after client disconnects
;   transaction  - after transaction finishes
;   statement    - after statement finishes
pool_mode = transaction
```

о умолчанию стоит в session, то есть, сессия будет удерживаться клиентом до тех пор, пока он не закроет соединение. Чаще всего значение имеет смысл заменить на transaction. В этом случае соединение будет возвращаться в общий пул после завершения транзакции. Значение statement означает, что соединение будет освобождаться после выполнения каждого отдельного выражения, чего вы почти наверняка не должны хотеть.

Настройки размера пула:

```
; total number of clients that can connect
max_client_conn = 1000
 
; default pool size.  20 is good number when transaction pooling
; is in use, in session pooling it needs to be the number of
; max clients you want to handle at any moment
default_pool_size = 20
 
;; Minimum number of server connections to keep in pool.
;min_pool_size = 0
```

Здесь я увеличил максимальное количество клиентских соединений до 1000. Значение, используемое по умолчанию, равно 100.

Настройки аутентификации:

```
; any, trust, plain, crypt, md5, cert, hba, pam
auth_type = md5
auth_file = /etc/pgbouncer/userlist.txt
```

… и доступа к админке pgbouncer:

```
;;;
;;; Users allowed into database 'pgbouncer'
;;;
 
; comma-separated list of users, who are allowed to change settings
admin_users = eax
 
; comma-separated list of users who are just allowed to use
;    SHOW command
;stats_users = stats, root
```

**Важно!** Параметр auth\_type по умолчанию имеет значение trust. То есть, PgBouncer будет пускать всех в базу данных без запроса пароля. Вы почти наверняка этого не хотите.

Файл /etc/pgbouncer/userlist.txt содержит имена пользователей и пароли, с которыми PgBouncer подключается к базе. Например:

```
"eax" "qwerty"
```

Пароли не обязательно хранить открытым текстом:

```
"eax" "md5175c641eaed0b6c05ae8444b73d789f0"
```

Здесь хэш `175c641e...` был посчитан как MD5 от пароля, следом за которым записано имя пользователя:

```
echo -n 'qwertyeax' | md5sum
```

Теперь, когда PgBouncer настроен, можно перезапустить его:

```
sudo service pgbouncer restart
```

… и ломиться в базу:

```
psql -p 6432 -U eax
```

Если все было сделано правильно, PgBouncer запросит пароль. В приведенном примере пароль, с которым пользователь ходит в PostgreSQL напрямую, и пароль, запрашиваемый PgBouncer — это один и тот же пароль. Если вдруг что-то не работает, рекомендую начать с проверки настройки аутентификации самого PostgreSQL (файл pg\_hba.conf).

Выше пользователь eax был добавлен в admin\_users, что дает ему доступ в админку PgBouncer. Вход в админку осуществляется так:

```
psql -p 6432 -U eax pgbouncer
```

Наиболее интересная из доступных команд — это перечитывание конфигурации без перезапуска сервера:

`RELOAD;`

Информацию о других доступных командах можно посмотреть так:

`SHOW HELP;`

Пример вывода:

```
DETAIL:
    SHOW HELP|CONFIG|DATABASES|POOLS|CLIENTS|SERVERS|VERSION
    SHOW FDS|SOCKETS|ACTIVE_SOCKETS|LISTS|MEM
    SHOW DNS_HOSTS|DNS_ZONES
    SHOW STATS|STATS_TOTALS|STATS_AVERAGES
    SET key = arg
    RELOAD
    PAUSE [<db>]
    RESUME [<db>]
    DISABLE <db>
    ENABLE <db>
    KILL <db>
    SUSPEND
    SHUTDOWN
```

Проверяем, что все работает, запустив pgbench с 900 соединенинями:

```
pgbench -i
pgbench -p 6432 -c 900 -C -T 60 -P 1
```



Если все было сделано правильно, pgbench будет превосходно работать, а команда `SHOW CLIENTS;`, выполненная в админке PgBouncer, покажет 900 соединений. При этом вывод `ps wuax | grep postgres` покажет, что реально запущено лишь 20 бэкендов PostgreSQL.