Як розрахувати max_connections для PostgreSQL та default_pool_size для pgbouncer?

Чи є правило чи щось, що я можу використати для обчислення хорошого числа max_connections, default_pool_sizeі max_client_conn?

Значення за замовчуванням є непарними. За замовчуванням PostgreSQL до max_connections = 100, тоді як pgbouncer за замовчуванням до default_pool_size = 20. Чи не повинен розмір default_pool_size завжди бути вище, ніж max_connections? Інакше в чому сенс? Я думав, що pgbouncer мав на меті дозволити нам обробляти більше з'єднань, зменшуючи їх накладні витрати (повторно використовуючи підключення PostgreSQL). Я збентежений.

Я шукаю поради, подібні до тих, що містяться у вікі PostgreSQL , наприклад "цей параметр повинен становити ~ 50% вашої пам'яті".

Я пам’ятаю, була таблиця для MySQL, яка дозволила вам обчислити такі параметри. Було б дивним мати щось подібне для PostgreSQL / pgbouncer.

Спочатку прочитайте наше канонічне питання щодо планування потенціалу .
^{_{Конкретна порада, яку ви просите, - це консультація щодо планування потенціалу, і вам доведеться розробити це самостійно, для вашого конкретного середовища.}}

По-друге, ви дивитесь на це неправильно.
Обсяг пам’яті (або будь-якого іншого ресурсу), який ви маєте, не диктує встановлену вами кількість підключень. Кількість потрібних підключень диктує, наскільки надійний сервер ви повинні придбати.
Вимоги до ресурсу для підключення наведені у посібнику досить докладно, а також обговорюються у Вікі, до якого ви пов’язані. З'ясуйте, що потребує ваше оточення (або зробіть здогадку про освіту) та переконайтесь, що обладнання, на якому ви збираєтеся працювати, може впоратися з тим, що ви збираєтеся кинути на нього.

Зокрема, щодо обмежень підключення та розміру пулу, у вас повинно бути "достатньо" підключень, щоб відповідати вимогам вашої програми - або на одному сервері, або через пул / вимикач.

"Досить" - відносне число: Додаток, який робить (і постійно повторно використовує) одне з'єднання, вимагає лише одного з'єднання. Додаток, який встановлює з'єднання для кожного кінцевого користувача, який входить, вимагає стільки ж з'єднань БД, скільки користувачів.

Значення за замовчуванням для обох Postgres і pgbouncerвони можуть бути за замовчуванням :

• 100 підключень до бази даних - це багато для типової людини, яка кидає Postgres в оточення.
  Можливо, розробникам не знадобиться більше 10. Будь-хто інший знатиме достатньо, щоб збільшити кількість.

• 20 підключень з pgbouncerпулу БД означають, що ви можете отримати 4 пули, що вказують на один сервер, і не перевищувати стандартний ліміт з'єднання Postgres.
  Можна pgbouncerвказувати кілька об'єднаних ресурсів, вказуючи на одну базу даних, і ви завжди хочете отримати кілька доступних з'єднань на своїх бек-серверах.

Якщо значення за замовчуванням не підходять для вашого оточення, очікується, що ви зміните їх.

Пам'ятайте, що об'єднані з'єднання не означають "завжди зв'язувати всі наявні підключення до бази даних".
Суть, pgbouncerяк ви зазначали, полягає у повторному використанні з'єднань. Підвищення ефективності тут не вимагає зв'язування кожного наявного з'єднання, а лише відключення, повторне узгодження, повторне узгодження SSL, повторна автентифікація до бази даних та повторне виконання запитів налаштування з'єднання кожного разу.

Зверніть увагу на визначення документаціїdefault_pool_size

Скільки можливих підключень до сервера на пару користувачів / бази даних.

Отже, якщо конфігурація за замовчуванням - розмір пулу 20, із 100 підключень, це означає, що 5 окремих пар користувачів / баз даних повинні мати максимум розмір пулу, перш ніж вони досягнуть загального ліміту. І навпаки, якщо ви, наприклад, використовуєте pgbouncer для маршрутизації до однієї бази даних через одного користувача, ваш ефективний ліміт з'єднання становить 20, а не 100, тому вам потрібно встановити розмір пулу для цього випадку використання. YMMV.