Как правильно настроить pgbouncer и postregsql?

Question

[Iceforest]

есть сервер базы данных с 16гб озу и 8 ядер
есть 20 бекендов, который ходят в базу с одинаковым логином и паролем
по нагрузке на базу +- 1500rps.
есть postgresql , в котором установлено max connections=100(по умолчанию)
есть pgbouncer pool mode=transaction, default_pool_size=20
правильно я понимаю, что max_client_conn это как раз моя нагрузка 1500 rps?то есть установить ее надо с запасом ~2000
1) правильная ли величина max connections установлена в postgresql?
2) какую цифру установить в max_client_conn в pgbouncer и какую в max_user_connections?

Answer 1

[Melkij]

max_client_conn в конфиге баунсера - это максимальное число возможных подключений от клиентов к самому баунсеру.
Если у вас max_client_conn стоит, например, 100, а каждый из 20 бекендов попробует открыть по 10 соединений с баунсером - то первая сотня подключений будет успешна, остальные получат ошибку "no more connections allowed (max_client_conn)"
max_client_conn ставится в 10000 и про него надолго забываем. Штука фактически бесплатная, libevent хорошо умеет с таким работать. Но требуется выставить корректный open file limit. Каждый коннект - это файловый дескриптор, если не скорректировать настройки ОС - то будет неприятный сюрприз.

Далее, max_connections базы оставить как есть. Максимум в 100 процессов базы на всего 8 ядер - это и так довольно-таки много, но и урезать смысла нет.
max_user_connections не трогать если нет причин для этого.

pool size 20 на всего лишь 8 ядер CPU может быть чрезмерно. Но далее нужно смотреть уже мониторинг. Сколько реальных процессов базы в работе, очередь ожиданий на баунсере, хватает ли баунсеру процессорного времени (тут скользкий момент, баунсер строго однопоточный и может упираться в производительность одного ядра CPU)

Comments

[Iceforest]

Melkij спасибо за развернутый ответ, а подскажи еще про pool size, как он коррелируетс с кол-во запросов в секунду? я так понял он должен быть равен кол-ву бекенд серверов

[Melkij]

pool size = сколько коннектов базы может использовать баунсер для комбинации имя_пользователя + имя_бд.
Может быть равен количеству бекенд серверов разве что по случайному совпадению.

при pool mode=transaction коннект базы предоставляется подключённому к баунсеру клиенту на время этой транзакции (запрос вне транзакции так же есть транзакция). Пришло условно одновременно 30 запросов от разных клиентов - при pool size 20, 20 клиентов получили по коннекту с базой и начали выполняться, остальные начинают ждать пока освободится коннект базы. После завершения транзакции освободившийся коннект передаётся следующему желающему что-то сделать с базой.

Один процесс базы не может выполнять одновременно два запроса, а значит получаем, что если запрос выполняется за 10мс, то при pool size 10 будет теоретический предел пропускной способности 1000rps.
При том, что очень важно, это не значит что на всего 8-ядерном CPU при pool size 20 будет возможно удвоить результат. Результат может стать даже хуже, потому что конкурентные процессы будут драться между собой за CPU и активно мешать друг другу работать.

Размер пула подбирается по действительной ситуации и по мониторингу.