Таким образом, идея использования pgbouncer состоит в том, чтобы объединять соединения, когда вы не можете позволить себе иметь большее количество max_connections в самой PG. ПРИМЕЧАНИЕ. Пожалуйста, НЕ устанавливайте для max_connections такие числа, как 2000.
Давайте начнем с примера, если у вас установлен лимит соединения в 20, а затем ваше приложение или организация хотят иметь 1000 соединений на через определенное время именно здесь приходит в голову пулер, и в этом конкретном случае c вы хотите, чтобы 20 пулов подключались к той 1000, приходящей из приложения.
Чтобы понять, как это на самом деле работает, давайте сделаем шаг назад и понять, что происходит, когда у вас нет пула соединений и вы полагаетесь только на настройку конфигурации PG для максимального количества соединений, которое в нашем случае равно 20.
Так что, когда соединение приходит от клиента \ приложения et c. основной процесс postgresql (PID, то есть идентификатор родителя) порождает ребенка для этого. Таким образом, каждое новое соединение порождает дочерний процесс под основным postgres процессом, например так:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
24379 postgres 20 0 346m 148m 122m R 61.7 7.4 0:46.36 postgres: sysbench sysbench ::1(40120)
24381 postgres 20 0 346m 143m 119m R 62.7 7.1 0:46.14 postgres: sysbench sysbench ::1(40124)
24380 postgres 20 0 338m 137m 121m R 57.7 6.8 0:46.04 postgres: sysbench sysbench ::1(40122)
24382 postgres 20 0 338m 129m 115m R 57.4 6.5 0:46.09 postgres: sysbench sysbench ::1(40126)
Итак, теперь, когда запрос на соединение отправляется, он принимается процессом POSTMASTER и создает дочерний процесс в Уровень ОС под основным родительским процессом. В этом случае срок службы этого соединения «неограничен», если только он не закрыт приложением или не установлено время ожидания для незанятых соединений в postgresql.
Теперь возникает ситуация, когда это может быть очень дорогостоящим делом. управлять соединениями с данным вычислением, если они превышают определенный лимит. Это означает, что n подключений при обслуживании имеют определенную стоимость вычислений, и через некоторое время ОС не сможет справиться с ситуацией с ОГРОМНЫМИ подключениями и, в свою очередь, вызовет конфликты на другом уровне вычислений (т. Е. Память, ЦП, ввод / вывод) .
Что если вы можете использовать порожденные в настоящее время дочерние процессы (бэкэнды), если они не выполняют никакой работы. Вы сэкономите время на получении дочернего процесса (бэкэнды), а также на дополнительных затратах (иногда они могут отличаться). Именно здесь пул соединений, которые всегда открыты, помогает обслуживать различные клиентские запросы и также называется пулом.
Таким образом, теперь в основном у вас есть только n доступных соединений, но диспетчер может управлять n + i числом соединения для обслуживания клиентских запросов.
Здесь pg-bouncer помогает повторно использовать соединения. Он может быть сконфигурирован с тремя типами пулов: пул сеансов, пул операторов и пул транзакций. По сути, bouncer возвращает соединение обратно в пул после того, как оно выполнено, на уровне операторов или на уровне транзакций и т. Д. c. Только при пуле сеансов он сохраняет соединения, если не отключается.
Так что, в основном, уменьшите количество соединений на уровне файла конф. PG и настройте все параметры в bouncer.ini.
Чтобы ответить на вторую часть:
еще один вопрос. в конфигурации pgpouncer правильно ли listen_addr = 0.0.0.0? или должно быть listen_addr = *?
Зависит от того, есть ли у вас автономное развертывание, сервер et c. в основном, если он находится на самом сервере, и вы хотите, чтобы он разрешал соединения отовсюду (входящие), используйте "*", если вы хотите, чтобы была разрешена только локальная сеть, используйте "127.0.0.0".
. Остальные вопросы проверьте эта ссылка: pgbouncer docs
Я попытался поделиться кое-чем из того, что я знаю, не стесняйтесь спрашивать, было ли что-то неясным или правильным, если оно было неправильно упомянуто.