Как рассчитать потребление оперативной памяти (RAM) базой данных PostgreSQL в зависимости от количества соединений (max_connections)?
Потребление оперативной памяти PostgreSQL напрямую зависит от количества активных соединений и ряда конфигурационных параметров. Рассмотрим подробную методику расчёта.
## Базовая формула расчёта RAM
Общее потребление памяти PostgreSQL можно оценить по следующей формуле:
**RAM_total = shared_buffers + (work_mem × max_connections × коэффициент) + maintenance_work_mem + wal_buffers + overhead**
## Ключевые параметры и их влияние
**1. shared_buffers**
Это общий буферный кэш, разделяемый между всеми процессами. Рекомендуется устанавливать в 25–40% от общего объёма RAM сервера. Например, при 32 ГБ RAM — около 8 ГБ.
**2. work_mem**
Память, выделяемая на каждую операцию сортировки или хэш-соединения внутри одного запроса. Критически важно: один запрос может использовать work_mem несколько раз (по числу узлов плана). Реальное потребление:
**work_mem_total = work_mem × max_connections × среднее_число_операций_на_запрос**
При work_mem = 4 МБ и max_connections = 200: минимум 800 МБ, реально — в 2–5 раз больше.
**3. maintenance_work_mem**
Используется для VACUUM, CREATE INDEX, ALTER TABLE. Рекомендуется 64–256 МБ. Не умножается на число соединений, но учитывайте параллельные autovacuum-воркеры (autovacuum_max_workers × maintenance_work_mem).
**4. wal_buffers**
Буфер для WAL-записей. Обычно 1/32 от shared_buffers, но не менее 64 КБ и не более 16 МБ.
**5. Накладные расходы на соединение**
Каждый процесс-бэкенд PostgreSQL потребляет около 5–10 МБ только на свою инфраструктуру (стек, структуры данных, кэш системных каталогов). При 200 соединениях это 1–2 ГБ дополнительно.
## Пример расчёта
Сервер с 32 ГБ RAM, max_connections = 200, work_mem = 8 МБ:
— shared_buffers = 8 192 МБ
— work_mem (пиковый) = 8 МБ × 200 × 3 = 4 800 МБ
— maintenance_work_mem = 256 МБ × 3 воркера = 768 МБ
— wal_buffers = 64 МБ
— Накладные расходы = 200 × 8 МБ = 1 600 МБ
— **Итого ≈ 15 424 МБ (~15 ГБ)**
## Практические рекомендации
— Используйте **PgBouncer** для пулинга соединений — это позволяет держать max_connections на уровне 100–200 даже при тысячах клиентов.
— Не устанавливайте work_mem слишком высоко при большом max_connections — риск OOM (Out of Memory).
— Формула безопасного work_mem: **(RAM — shared_buffers) / (max_connections × 3)**.
— Мониторьте реальное потребление через `pg_stat_activity` и системные утилиты (htop, ps).
— Параметр `effective_cache_size` не резервирует память, а лишь подсказывает планировщику — не включайте его в расчёт реального потребления.