Управление пулом соединений осуществляется в первую очередь с помощью двух параметров конфигурации: session_pool_size и max_sessions. Для включения пула соединений в параметре session_pool_size нужно задать ненулевой размер пула. С любым положительным значением max_sessions Postgres Pro будет задействовать пулы обслуживающих процессов для работы со всеми базами данных, за исключением баз postgres, template0 и template1, которые по умолчанию считаются выделенными.

Переменная session_pool_size устанавливает максимальное число обслуживающих процессов в пуле для определённой комбинации база данных/пользователь. Таким образом, общее число обслуживающих процессов, работающих в пуле, ограничивается значением session_pool_size * N * M, где N — число баз, а M — число пользователей, работающих с этими базами. Оптимальное значение session_pool_size во многом зависит от системных ресурсов. Если значение будет слишком маленьким, сервер не сможет использовать все имеющиеся ресурсы, а если слишком большим, производительность может снизиться из-за постоянных конфликтов блокировок и снимков.

Параметр max_sessions определяет максимальное число сеансов, которые могут обслуживаться одним процессом. Таким образом, максимальное число подключений для одной базы данных/пользователя ограничивается значением session_pool_size * max_sessions. От параметра max_sessions зависит только потенциальный размер очереди в каждом обслуживающем процессе; негативного влияния на потребление ресурсов он не оказывает. Значение по умолчанию — 1000.

Кроме того, вы можете настроить количество приёмников, которые будут получать стартовые пакеты клиентов и определять, к какому конкретному пулу должно относиться соединение. По умолчанию используется два процесса-приёмника. Изменить это число позволяет параметр конфигурации connection_pool_workers.

Если вы планируете использовать подготовленные транзакции (2PC) в сеансах, обслуживаемых пулом, обязательно включите параметр конфигурации hold_prepared_transactions, допускающий переключение процесса на другой сеанс только после того, как все подготовленные транзакции в текущем сеансе будут зафиксированы или отменены. Это предотвращает конфликты, которые могут возникнуть между подготовленными транзакциями разных сеансов в одном процессе и вызвать неявные взаимоблокировки.

Postgres Pro позволяет отключить использование пула для некоторых баз данных, чтобы для каждого соединения запускался отдельный процесс. Такие базы данных называются выделенными. Количество обслуживающих их процессов не ограничивается, так что клиентам не нужно ждать освобождения одного из общих процессов в пуле — они могут обращаться к своим базам данных немедленно.

Чтобы база данных считалась выделенной, укажите её имя в параметре конфигурации dedicated_databases и вызовите функцию pg_reload_conf(). По умолчанию выделенными считаются базы postgres, template0 и template1.

Так как postmaster распределяет сеансы клиентов между обслуживающими процессами в момент подключения, нагрузка может распределиться неравномерно: одни процессы будут простаивать, а другие будут перегружены, и подключённые к последним клиенты столкнутся с задержками при выполнении запросов. Для изменения метода распределения сеансов между процессами предназначен параметр конфигурации session_schedule, определяющий политику распределения. Воспользовавшись им, вы можете выбрать политику round-robin (по порядку; это вариант по умолчанию), random (случайное распределение) и load-balancing (распределение нагрузки).

Политики random и round-robin должны хорошо работать с равномерными нагрузкой, однако если характер нагрузки иной, более подходящей может быть политика load-balancing. С такой политикой postmaster выбирает для нового подключения процесс с наименьшей нагрузкой, которая определяется по числу сеансов, ожидающих выполнения транзакций в данном процессе.

Вы можете проверить текущую нагрузку обслуживающего процесса, вызвав функцию pg_backend_load_average(pid), где pid — идентификатор интересующего вас процесса. К сожалению, даже с самым удачным распределением во время подключения нельзя гарантировать, что характер нагрузки не изменится в будущем: некоторые сеансы могут завершиться, а простаивающие сеансы могут в любой момент активироваться.

Процессы, запускаемые для обслуживания подключающихся клиентов, продолжают работать и тогда, когда все их клиенты отключаются. Хотя это позволяет повторно использовать освободившиеся процессы для будущих подключений, иногда возникает потребность завершить их. Например, вы не сможете удалить базу данных или пользователя, пока в связанном с базой или пользователем пуле работает хотя бы один процесс.

Чтобы завершить неиспользуемые обслуживающие процессы без перезапуска сервера, можно сделать следующее:

Также можно задать параметр конфигурации idle_pool_worker_timeout, чтобы неиспользуемые процессы завершались и системные ресурсы освобождались автоматически после заданного тайм-аута.