Комментарии 8
Есть ли слухи/надежды/шансы в комьюнити, что однажды прокси-решение типа pgbouncer (или ваше, не важно - я больше спрашиваю концептуально) будет встроено в само ядро PostgreSQL? Примерно как это в свое время произошло с php-fpm: он долго был независимым проектом, а потом его встроили прямо в ядро. Кажется, что встроенного пулера коннектов очень сильно не хватает (часто люди ставят 3-5 штук pgbouncer’ов на ту же самую машину, что и PostgreSQL, просто чтобы ограничить число процессов, и этого хватает для достаточно значительного масштабирования клиентов - 30000 клиентских персистентных коннектов оно держит в такой конфигурации легко).
Для чего люди ставят 3-5 штук pgbouncer’ов на одну машину, а не используют один?
Он однопоточный, CPU упирается в потолок, особенно когда идет спайк новых ssl-соединений от клиентов.
Спасибо за ответ! Интересно, а почему pgbouncer не сделают многопоточным, с возможностью настройки, сколько потоков он может использовать? Иначе ведь нам нужно еще как-то балансировать на какой из pgbouncer идти?
для многопотока в яндексе придумали одиссей
Что касается «почему в pgbouncer не сделают» - там уже никогда ничего не сделают, проект старый, код старый, порос мхом и лишайником. Но он все равно самый популярный, т.к. по инерции идет репутация, плюс все давно обложили костылями существующие баги и неудобства.
Балансировать несколько процессов pgbouncer я люблю через ipvsadm. Немного кривовато (на localhost его слушать мне так и не удалось заставить - только на реальном ip-адресе), зато честный round robin и максимально низкие накладные расходы.
В postgres pro enterprise был свой встроенный пул до 16 версии https://postgrespro.ru/docs/enterprise/16/connection-pooler-configuration
Начиная с 17 версии вместо него https://postgrespro.ru/docs/enterprise/17/proxima
Вышел релиз СУБД Postgres Pro Enterprise 17