Глава 34. Встроенный пул соединений

Важно

Функциональность встроенного пула соединений считается устаревшей. Вместо неё используйте расширение pgbouncer или другой внешний инструмент.

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

В большинстве инсталляций Postgres Pro для ограничения числа запускаемых обслуживающих процессов применяются внешние средства, например, J2EE, odyssey или pgbouncer, один из наиболее популярных пулов соединений для Postgres Pro. Однако применение внешних пулов соединений подразумевает дополнительные издержки, связанные с их установкой, настройкой и сопровождением. Кроме того, если пул работает в одном потоке, как pgbouncer, вам также придётся запускать несколько экземпляров пула, чтобы он не оказался узким местом в сильно нагруженных системах.

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

В следующих разделах описывается архитектура встроенного пула соединений и приводятся инструкции по его настройке.

Chapter 34. Built-In Connection Pooling

Important

The built-in connection pooler functionality is deprecated. Use the pgbouncer extension or another external tool instead.

When establishing a connection, PostgreSQL spawns a separate backend process for each client. For a large number of clients, this model can cause high consumption of system resources and lead to significant performance degradation, especially on multicore systems. The reason is high contention for PostgreSQL resources between backends. Besides, the size of many PostgreSQL internal data structures is proportional to both the complexity of algorithms for these structures and the number of active backends.

Most production Postgres Pro installations reduce the number of spawned backends using external tools, such as J2EE, odyssey, or pgbouncer, one of the most popular connection poolers for Postgres Pro. However, external connection poolers require additional efforts for installation, configuration, and maintenance. If the pooler is single-threaded, like pgbouncer, you also have to launch multiple pooler instances as it can otherwise cause a bottleneck on high-load systems.

To address these challenges, Postgres Pro Enterprise provides a built-in connection pooler. Unlike external solutions, it does not require any additional maintenance and does not introduce any limitations for clients. With built-in connection pooling enabled, clients can continue using session configuration parameters, prepared statements, and temporary tables as if there is no proxy.

The chapters that follow describe built-in connection pooler architecture and provide configuration instructions.

FAQ