Всем привет, у меня вопрос. Рекомендация нашими субд выставлена, что

максимальное количество коннектов должно быть кратно cpu тачки. То есть на 6 ядер, 18 потоков. Все что выше, юзать пгбаунсер. У меня вопрос, кому то встречалась в документации пг, эта информация?

Обычно рекомендуют наоборот выкручивать коннекшены на максимум, ну 1000+ точно делать. PgBouncer это прекрасно и вообще жизнь облегчит, но таких рекомендаций не видел ни разу.

нет, не рекомендуют делать 1000+. надо начать с анализа того, какая доля этих 1000+ реально работает, и сколько там простаивает — вторую часть как раз и можно подрезать, через конфигурацию пулов приложения.

Интересует мат часть и зависимость cpu от коннектов

В документации именно такой рекомендации точно нет. Что-то отдалённо похожее (я подчеркнул) написано только в ( https://www.postgresql.org/docs/current/kernel-resources.html ): "If PostgreSQL itself is the cause of the system running out of memory, you can avoid the problem by changing your configuration. In some cases, it may help to lower memory-related configuration parameters, particularly shared_buffers, work_mem, and hash_mem_multiplier. In other cases, the problem may be caused by allowing too many connections to the database server itself. In many cases, it may be better to reduce max_connections and instead make use of external connection-pooling software." Но, вообще, похожие рекомендации нередко встречаются, к примеру: https://www.enterprisedb.com/postgres-tutorials/introduction-postgresql-performance-tuning-and-optimization#maxconnections (и в общем понятно, чем они обоснованы — если активных процессов больше, чем CPU cores, то производительность (в смысле общей пропускной способности) неизбежно страдает; да и per-connection overhead тоже может быть существенным, особенно при неправильной настройке OS). С другой стороны, тут есть тонкость — размер многих внутренних структур данных "завязан" на max_connections (формулы обычно вроде max_connections * что-то), и, как мне кажется, во многих из них неявно заложено, что значение будет хотя бы 100 (чаще всего расчёт на то, что сессии будут использовать эти ресурсы [очень] неравномерно). Просто в качестве иллюстрации — выполнить pg_dump базы, в которой таблиц больше, чем примерно (c точностью до константы, которую я забыл) max_connections * max_locks_per_transaction, не удастся.

А где Вы видели такую рекомендацию (тем более, "обычно")?!

О спасибо. Сяду оценю, надо еще бы нт тесты глянуть

В документации наверное нигде, на ряде курсов такое рекомендуют. Но давайте объективно, реальный сервер БД (с 10-15 приложениями), без баунсера и с хотя бы 50 юзерами. 100 коннекшенов?

Я могу озвучить более реальные цифры, 6 приложений. Каждый от 1 до 10 коннешкинов, у каждого приложения 2 экземпляра. Того 120 коннектов в пике. База пг на вм, CPU 6

Никаких проблем вообще.

а у вас все 50 юзеров открывают соединения и висят в них?

> В документации наверное нигде Я знаю, что в документации такого точно нет. > на ряде курсов такое рекомендуют А по каким причинам? > Но давайте объективно, реальный сервер БД (с 10-15 приложениями), без баунсера и с хотя бы 50 юзерами. Да, давайте. На реальном сервере сочетания подчёркнутых фактов быть не должно. ;) Иначе может случиться вот так (см. "Risk of overloading the database"): https://www.cybertec-postgresql.com/en/tuning-max_connections-in-postgresql/ Кстати, производительность каких-то внутренних функций в PostgreSQL раньше зависела от max_connections как O(n²) — не знаю, "вылечили" ли всё это сейчас (не слежу).

Про документацию - ок, я тоже нигде не встречал. Про курсы - 100 мало, надо или баунсер или 1000+ коннекшенов, если приложения очень активно юзают бд. Про реальный сервер согласен, тоже считаю, что без баунсера это работать не должно. За ссылку большое спасибо, что-то подобное уже читал, но интересно.

Нет конечно, но не все запросы и не всегда отрабатывают за 1 секунду, если мы не про таблички с 100-1000 записей.

так в каких случаях нужно 1000+ я так и не понял

На входе был вопрос: сколько можно без баунсера.

Если нужно, чтобы было ≈ 1000 одновременно активных соединений (очень хорошо, если при этом есть ≈ 300 CPU cores ;) ) и готовность "выбросить" под это дело ≈ 2 GB RAM — придётся ставить и разбираться с проблемами по мере возникновения, как мне кажется.

Ну так "Почему - как набор рекомендаций, не более." пока похоже на очередной [идиотский] совет из области "мифов и легенд PostgreSQL", вроде "отключи autovacuum", или "партиционируй всё", или "выполняй VACUUM FULL ежедневно"... и т.д. и т.п. ;)