Рекомендации по настройке и использованию

Pangolin Pooler используется для снижения количества соединений с БД, потому что каждая сессия БД потребляет ресурсы RAM и CPU.

Как правило, постепенное или неограниченное увеличение количества активных пользовательских сессий в БД приводит к следующим сценариям:

• Производительность СУБД перестает расти и начинает деградировать для большинства профилей нагрузки.
• Повышается утилизация CPU и RAM-сервера вплоть до OОM killer.

Оптимальное количество соединений с БД фиксируется параметром max_connections, и его значение должно определяться на этапе нагрузочного тестирования, исходя из профиля нагрузки и возможностей КТС.

Настройка max_connections

Параметр max_connections задает максимальное количество одновременных подключений к серверу СУБД. Для каждого подключения создается отдельный процесс в операционной системе. По умолчанию значение составляет 100, но оно может быть снижено, если ядро накладывает свои ограничения – это определяется во время инициализации кластера (initdb). Параметр можно изменить только при запуске сервера.

При использовании репликации рекомендуется устанавливать одинаковое значение max_connections как на Primary, так и на StandBy-серверах. Это связано с тем, что в случае переключения роли (например, при автоматическом failover), StandBy может стать новым Primary, и если у него установлено меньшее значение max_connections, часть пользователей может не получить подключение.

Рекомендации по определению значения параметра

Параметр конфигурации СУБД max_connections устанавливается как максимальное количество одновременных соединений, которое, будет использоваться при пиковой нагрузке. Каждое соединение использует shared_buffer-память, а также дополнительную неразделяемую память.

Точное значение данного параметра вычисляется на нагрузочном тестировании (далее – НТ) для профиля нагрузки. Среднестатистически, при установке значения, вычисляется по этой формуле max_connections = GREATEST (5 x CPU cores, 100).

Предупреждение!

Проверьте значениеmax_connections после формирования конфигурации с помощью Pangolin Tuner.

Значение max_connections в сформированной конфигурации не является универсальным для всех профилей нагрузки. Для профилей, при которых приложение создает большое количество клиентских подключений, может потребоваться ручное изменение параметра. Например, такая ситуация возможна для профиля 1C.

Подтвердите выбранное значение max_connections нагрузочным тестированием. При проверке учитывайте:

• пиковое количество одновременных подключений приложения;
• доступные ресурсы RAM и CPU;
• параметры Pangolin Pooler, если он используется;
• значение superuser_reserved_connections;
• одинаковость значения max_connections на узлах, которые могут выполнять роль Primary.

Не увеличивайте max_connections без оценки ресурсов сервера. Увеличение значения повышает максимальное количество серверных процессов и объем ресурсов, которые СУБД может выделить для обслуживания подключений. При недостатке RAM или CPU это может привести к деградации производительности, ошибкам подключения или завершению процессов операционной системой, например через OOM killer.

После изменения max_connections перезапустите сервер СУБД.

Pangolin Pooler рекомендуется использовать, когда приложение создает превышающее max_connections количество клиентских подключений (max_client_conn > max_connections) для оптимизации производительности СУБД и экономии ресурсов RAM и CPU-сервера.

Следует придерживаться следующих правил:

• Значение max_db_connections <= max_connections - superuser_reserved_connections - 30.
• Выставление параметров min_pool_size = default_pool_size позволяет избежать накладных расходов на повторное открытие и закрытие соединений.

Пример сбалансированной конфигурации, когда один пользователь (ТУЗ) работает с одной БД:

• max_client_conn = 1000;
• pool_mode = transaction;
• min_pool_size = 200;
• default_pool_size = 200;
• max_db_connections = 200;
• max_user_connections = 200.

Подобное соотношение позволяет эффективно использовать соединения к СУБД, одновременно обслуживая большое количество клиентов.

Подсказка

Стоит отметить, что эффективность использования пулера достигается тогда, когда значение max_db_connections значительно меньше, чем max_client_conn. В этом случае Pangolin Pooler агрегирует множество клиентских соединений и переиспользует ограниченное число подключений к СУБД, тем самым снижая нагрузку и увеличивая масштабируемость.

Если же значения max_db_connections и max_client_conn равны или близки, то пулер фактически перестает выполнять свою функцию — каждое клиентское соединение напрямую транслируется в подключение к базе данных. Это приводит к тому, что Pangolin Pooler становится просто промежуточным звеном, замедляющим работу.

То же самое происходит в режиме работы pool_mode = session, в котором Pooler повторяет прямое подключение к СУБД Pangolin, но может значительно снижать производительность и надежность, относительно прямого подключения на порт СУБД.

Стоит обратить внимание, что параметр default_pool_size задается для пары пользователь/БД, поэтому для каждой созданной БД или подключаемого пользователя потенциально может открываться default_pool_size * total databases * total users соединений. Это необходимо учитывать при настройке параметров max_db_connections и max_user_connections, которые задаются независимо от пользователя и БД соответственно. В таких случаях рекомендуется явно ограничивать количество подключений через параметр pool_size в секции databases для каждой созданной БД.

Pangolin Pooler является однопоточным приложением, поэтому важно следить за утилизацией ядра CPU, на котором оно работает. Также не исключается взаимовлияние серверных процессов и Pangolin Pooler друг на друга в случае работы на одном ядре.

Работа через Pangolin Pooler замедляет отклик от БД в среднем на 5%, так как весь входящий и исходящий трафик проходит через него.

Pangolin Pooler не рекомендуется использовать:

• Когда ядро, на котором работает Pangolin Pooler, нагружено более чем на 70%.
• В режимах работы pool_mode = session/statement.
• В режимах работы pool_mode = transaction, при OLTP нагрузках с требованиями более 1000-10000 tps и длительностью операции менее 1-10мс из-за накладных расходов при работе с сокетом, который диагностируется ростом sys_time на CPU.
• В конфигурациях, когда количество клиентских подключений в пределе достигает количества подключений к БД (max_client_conn = max_db_connections при использовании одной БД).
• Для OLAP-нагрузок, требующих большого трафика через Pangolin Pooler.

Пример потенциально нежелательной конфигурации, когда один пользователь (ТУЗ) работает с одной БД:

• max_client_conn = 1000 и более;
• default_pool_size = 1000 и более;
• max_db_connections = 1000 и более;
• max_user_connections = 1000 и более.

Стоит обратить внимание, что перед настройкой параметров подключения Pangolin Pooler необходимо убедиться, что параметр СУБД max_connections обеспечивает требуемое количество подключений и в случае необходимости изменить его.

При создании подключений через HikariCP на стороне приложения в максимальном количестве менее, чем max_connections, рекомендуется подключаться напрямую к БД. Однако в случае, когда суммарное количество клиентских подключений превышает max_connections, рекомендуется использовать Pangolin Pooler в связке с HikariCP, предварительно настроив параметры групп соединений и тайм-аутов с двух сторон:

• Параметр max_client_conn должен превышать сумму всех возможных подключений с HikariCP, равную hosts * maximum - pool_size.
• Тайм-аут на подключение на клиенте должен быть выше, чем на Pangolin Pooler.