Как рассчитать лимит соединений для PostgreSQL (max_connections) исходя из параметров CPU и RAM выделенного сервера?
Параметр `max_connections` в PostgreSQL определяет максимальное количество одновременных клиентских соединений с сервером базы данных. Неправильно выбранное значение приводит либо к отказам в подключении, либо к деградации производительности из-за избыточного потребления памяти и конкуренции за ресурсы.
## Почему важно правильно рассчитать max_connections
Каждое соединение в PostgreSQL — это отдельный процесс на уровне ОС. Каждый такой процесс потребляет:
— **5–10 МБ оперативной памяти** в базовом состоянии (без активных запросов).
— Дополнительную память при выполнении запросов: `work_mem` умножается на количество операций сортировки/хэширования внутри одного запроса.
## Основная формула расчёта
Наиболее распространённая практическая формула:
max_connections = (RAM_GB * 1024 / work_mem_MB) / 2
Где `work_mem` — объём памяти на одну операцию сортировки/хэширования (по умолчанию 4 МБ, рекомендуется 16–64 МБ для OLTP).
**Пример:** Сервер с 32 ГБ RAM, work_mem = 16 МБ:
(32 * 1024 / 16) / 2 = 2048 / 2 = 1024 соединения
Это теоретический максимум. На практике рекомендуется брать 50–70% от расчётного значения.
## Роль CPU в расчёте
CPU влияет на параллелизм: PostgreSQL рекомендует не более **2–4 активных соединений на одно ядро** для OLTP-нагрузки. Для аналитических запросов — ещё меньше.
**Формула с учётом CPU:**
max_connections = min(CPU_cores * 4, RAM_GB * 50)
**Пример:** 8 ядер, 32 ГБ RAM:
min(8 * 4, 32 * 50) = min(32, 1600) = 32 активных соединения
Здесь важно разграничивать **активные** соединения (реально выполняющие запросы) и **пул соединений** (включая idle-соединения).
## Рекомендуемые значения по конфигурациям
| RAM / CPU | Рекомендуемый max_connections |
|————|——————————-|
| 4 ГБ / 2 ядра | 50–100 |
| 8 ГБ / 4 ядра | 100–200 |
| 16 ГБ / 8 ядер | 200–400 |
| 32 ГБ / 16 ядер | 300–600 |
| 64 ГБ / 32 ядра | 500–1000 |
## Использование пулера соединений
Для высоконагруженных систем рекомендуется не увеличивать `max_connections` до предела, а использовать **PgBouncer** или **Pgpool-II**. Пулер принимает тысячи клиентских соединений и мультиплексирует их в небольшое количество реальных соединений к PostgreSQL (обычно 20–100).
## Итоговый алгоритм
1. Определите `work_mem` исходя из типа нагрузки (OLTP: 16–32 МБ, OLAP: 64–256 МБ).
2. Рассчитайте максимум по RAM: `(RAM_MB / work_mem_MB) / 2`.
3. Рассчитайте максимум по CPU: `CPU_cores * 4`.
4. Возьмите меньшее из двух значений.
5. Оставьте запас 20–30% для системных нужд.
6. При необходимости более 200 соединений — рассмотрите PgBouncer.
Правильная настройка `max_connections` в связке с `work_mem`, `shared_buffers` и пулером соединений позволяет максимально эффективно использовать ресурсы сервера.