Есть ли какое-то правило или что-то, что я могу использовать, чтобы вычислить хорошее число для 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.
Во-первых, пожалуйста прочтите наш канонический вопрос о планировании мощностей.
Конкретный совет, который вы просите, - это совет по планированию мощности, и вам придется работать с ним самостоятельно, для вашей конкретной среды.
Во-вторых, вы неправильно на это смотрите.
Объем памяти (или любого другого ресурса), который у вас есть, не определяет количество установленных вами подключений, количество подключений, которые вы необходимость определяет, насколько мощный сервер вы должны приобрести.
Требования к ресурсам для каждого соединения приведены в руководство достаточно подробно, а также обсуждено в Wiki, на которую вы ссылаетесь. Выясните, что нужно вашей среде (или сделайте обоснованное предположение), и убедитесь, что оборудование, на котором вы собираетесь работать, может справиться с тем, что вы собираетесь на него бросить.
В частности, в отношении ограничений на количество подключений и размера пула, у вас должно быть «достаточно» подключений для удовлетворения требований вашего приложения - либо на одном сервере, либо через пул / баунсер.
«Достаточно» - это относительное число: приложение, которое устанавливает (и постоянно повторно использует) одно соединение, требует только одно соединение. Приложение, которое устанавливает соединение для каждого входящего в систему конечного пользователя, требует столько соединений с БД, сколько у него пользователей.
Значения по умолчанию для Postgres и pgbouncer разумны как значения по умолчанию:
100 подключений к базе данных - это много для обычного человека, использующего Postgres в среде.
Разработчикам, вероятно, не понадобится больше 10. Любой другой будет знать достаточно, чтобы увеличить это число.
20 контактов из pgbouncer на пул БД означает, что вы можете получить 4 пула, указывающих на один сервер, и не превысить лимит подключений Postgres по умолчанию.
Возможно наличие нескольких объединенных ресурсов в pgbouncer указывая на одну внутреннюю базу данных, и вам всегда нужны доступные соединения на ваших внутренних серверах.
Если значения по умолчанию не подходят для вашей среды, вы должны их изменить.
Помните, что объединенные соединения не означают «всегда связывать каждое доступное соединение с базой данных».
Смысл pgbouncer как вы отметили, это повторное использование соединения. Повышение эффективности здесь не требует, чтобы вы связали каждое доступное соединение, просто вы не отключаете, не повторно подключаетесь, не повторно согласовываете SSL, не повторно аутентифицируетесь в базе данных и не повторно запускаете запросы настройки подключения каждый раз.
Уведомление определение в документации default_pool_size
Сколько подключений к серверу разрешить для каждой пары пользователь / база данных.
Таким образом, если конфигурация по умолчанию представляет собой размер пула 20 из 100 соединений, это означает, что 5 различных пар пользователь / база данных должны будут максимально увеличить размер пула, прежде чем они достигнут общего предела. И наоборот, если, например, вы используете pgbouncer для маршрутизации к одной базе данных через одного пользователя, ваш эффективный предел подключения будет 20, а не 100, поэтому вам необходимо соответственно установить размер пула для этого варианта использования. YMMV.