Значение по умолчанию 100 весьма скромное, обычно выставляют значение от 1 тыс и выше, в завимости от возможностей сервера.
Известно, что при чрезмерном числе одновременных соединений производительность сервера БД и скорость выполнения запросов падают.
Заметим, что начиная с 17 версии в документации появилось утверждение:
PostgreSQL определяет размер некоторых ресурсов в зависимости от значения max_connections. Увеличение этого значения приводит к выделению большего объёма этих ресурсов, включая общую память.
Какие ресурсы здесь подразумеваются? И как определяется их размер, по каким формулам?
Некоторые источники рекомендуют использовать max_connections при расчете значения work_mem
Код: Выделить всё
Total RAM * 0.25 / max_connectionsНо нужен резерв соединений для специальных пользователей, обеспечивающих работу сервера БД, например для агентов мониторинга, заданий обслуживания сервера БД и т.п.
Без резерва при высокой нагрузке с большим числом одновременных подключений они могут столкнуться с сообщением об ошибке FATAL: sorry, too many clients already
В целях резервирования слотов подключений иногда используют "типовой" подход, состоящий в том, чтобы указывать лимит подключений CONNECTION LIMIT предел_подключений в атрибутах пользователей CREATE/ALTER ROLE/USER
Общий лимит подключений пользователей определяется как max_connections - резерв слотов для специальных пользователей.
Но пользователей БД, как и приложений, работающих с базой данных, может быть два или более. Поэтому "жестко" и правильно распределить между ними лимиты подключений БД не всегда возможно.
Например, предположим с сервером БД работают два приложения которые подключаются под пользователями user1 и user2.
Также выставлено max_connections = 100, из них 10 подключений резервируется для специальных пользователей.
Вариант 1. Выставить CONNECTION LIMIT в 50% из числа доступных каждому приложению:
user1 = 45 и user2 = 45
Даже если user2 не использует подключения, user1 будет упираться в лимит 45 подключений. Это излишне ограничивает число подключений приложения.
Вариант 2. Выставить CONNECTION LIMIT в 100% из чисоа доступных каждому приложению:
user1 = 90 и user2 = 90
Если оба приложения активно используют подключения, например в часы высокой нагрузки, они получат сверх доступного числа подключений и для специальных пользователей есть риск столкнуться с FATAL: sorry, too many clients already
Отличная новость, что начиная с версии PostgreSQL 16 появились весьма полезные роль pg_use_reserved_connections и соответствующий параметр подключения reserved_connections
Из документации:
Параметр reserved_connections определяет количество «слотов» подключений, которые PostgreSQL будет резервировать для ролей с правами роли pg_use_reserved_connections. Когда число активных одновременных подключений больше superuser_reserved_connections, но меньше суммы superuser_reserved_connections и reserved_connections, принимаются только подключения суперпользователей и ролей с правами pg_use_reserved_connections. Если количество подключений меньше или равно superuser_reserved_connections, принимаются только подключения суперпользователей.
По умолчанию подключения не резервируются (параметр имеет нулевое значение). Это значение должно быть меньше значения max_connections минус superuser_reserved_connections. Задать этот параметр можно только при запуске сервера.
Таким образом, возможно зарезервировать «слоты» подключений для специальных пользователей с грантованной ролью pg_use_reserved_connections, даже если они не являются супервпользователями, и потребность жестко ограничивать подключения через CONNECTION LIMIT остальным пользователям отпадет.