А зачем вам вообще pgbouncer? Это крайне нишевое решение для софта, который открывет/закрывает соединения на каждое выполнение, десятками и сотнями в секунду (веб на perl-скриптах и т.п.). ИМХО, это специально надо писать все имеющиеся системы, чтобы так извращённо работать с БД. И не забывайте, что pgbouncer - однопоточная штука.

А по делу возразить можете?

Максим, расскажите подробнее об архитектурных проблемах postgresql с сотнями и тысячами idle коннектов с закрытыми транзакциями. Я такого не наблюдал, ну кроме очевидных нюансов со стороны ОС.

Что касается сотни бэкендов, каждый со своим пулом: такая конструкция будет в большей степени ограничена предельным количеством активных сессий, после которого эффекты конкуренции за ресурсы (процессор, диски, блокировки, кэш и т.д.) приведут к неприемлемому росту времени отклика. Значит, суммарный для всех одновременно доступных бэкендов лимит на количество соединений в пуле не должен быть выше этого количества. Да, я знаю, как организационно сложно этого добиться, но это решаемая задача.

Вы сами читали эту ерунду или специально тратите моё время?

Товарищ Фернандо в неком синтетическом тесте на 56-процессорной машине получает 4506 TPS при работе с Postgresql напрямую в 56 потоков утилиты-нагружалки. На том же железе при увеличении числа потоков нагружения производительность внезапно падает. Contention и прочие страшные слова Фернандо, видимо, не знакомы - во всяком случае, исследовать проблему падения производительности он не пытается (или не пишет об этом), каких-либо метрик загруженности не приводит.

Пациент не унимается, и втыкает один экземпляр pgbouncer между нагружалкой и Postgresql и в нём получает 1800 TPS при любом количестве потоков нагружения и размере пула pgbouncer, равном 56. При увеличении размера default_pool_size в какой-то момент производительность внезапно падает.

При этом в начале статьи вполне корректно расписывается, чем плохо постоянно открывать/закрывать соединения, но вот сам скрипт нагружения https://github.com/Percona-Lab/sysbench-tpcc/blob/master/tpcc.lua соединение открывает в методе thread_init(), который выполняется один раз для каждого потока при запуске утилиты - см. https://www.percona.com/blog/2019/04/25/creating-custom-sysbench-scripts/ , т.е. конкретно в этой утилите нагружения проблемы, с которой собрался героически бороться пациент, вообще нет - все свои 56 или сколько задано через параметр "--threads" подключений утилита открывает при запуске, держит в ходе всей работы и закрывает по окончании.

В итоге делается вывод, что в каких-то сценариях pgbouncer может помочь улучшить производительность. Фернандо, правда, так и не смог выжать из конфигурации с pgbouncer больше 1821 TPS супротив 4506 TPS без него, но ведь это тоже улучшение, просто отрицательное! :) Впрочем, выжать что-либо он и не пытался, а довольствовался полученными результатами, хоть и имеющими нулевую практическую ценность.

Максим, спасибо за развёрнутый ответ!

1)у postgresql 1 коннект - 1 процесс...
Это значит что при 1000 коннектов имеем:

1000 регулярно активных процессов нагружают cpu scheduler, вызывают постоянное вымывание кеша процессора и лишние переключения контекста и миграции процессов между сокетами
Всё то же самое вызовут и 100 процессов, выполняющие работу этих 1000. Scheduler-у измеримой разницы нет, сколько процессов в системе - сто или тысяча или десять тысяч, а все остальные проблемы зависят от количества выполняемой работы, а не количества процессов, которые эту работу делают.

1000 процессов базы в пределе занимают (и легко могут занимать) 1000*work_mem например 32GB памяти просто на себя при не сильно большом 32MB work_mem
Бесспорно, но это очевидные накладные расходы ОС, их я понимаю. Также такая история будет свидетельством того, что все бэкенды в какой-то момент могут раздувать и полностью использовать свои пулы коннектов.

1000 процессов базы когда у вас будет много shared buffers (ну там 100 или 200GB) и не включены huge_pages....
Я не знаток Linux, но насколько могу понимать, при shared buffers в сотни гигабайт неиспользование HugePages - это целенаправленное вредительство.

вы получите в пределе еще 100-200GB занятых в PageTables памяти ядра системы
В Solaris для решения подобных проблем есть Intimate Shared Memory, а в Linux, насколько я понимаю, при использовании HugePages таких проблем тоже не будет.

Внутренние структуры (ProcArray) у postgresql очень фигово масштабируются на тысячи коннектов и там начинается очень большой overhead и потери на сихронизацию в 2 и 4х сокетных серверах.
А вот это интересно. Можете поподробнее раскрыть тему? И почему многосокетные системы страдают, а, многоядерные, но с одинм сокетом, получается, нет? И зачем Postgresql лезть во внутренние структуры процессов сильно глубоко, если очевидно, что процесс, не выполнявший с предыдущего его обхода никакой полезной работы, своё состояние или состояние разделяемых между процессами ресурсов не изменил? Тут хорошая аналогия с scheduler-ом ОС - если у треда стоит флаг TS_RUN, то есть потребность что-то делать и ставить его в очередь на выполнение, а если нет, то и делать ничего не надо и можно переходить к следующему треду (утрирую).

Что же касается "Значит, суммарный для всех одновременно доступных бэкендов лимит на количество соединений в пуле не должен быть выше этого количества. " - фиг там не работает оно так... потому что сейчас одному backend надо 1 коннект а другому 40... через секунду наоборот...
Мне кажется, у Вас что-то или с бэкендами или с балансировщиком перед этими бэкендами. Как исключить ситуацию, когда все бэкенды захотят 40 коннектов каждый? Если ограничивать это pgbouncer-ом или не важно чем ещё, Вы просто упрётесь в лимиты этого ограничителя и потеряете время отклика.