max_connections
Тема дорожной карты · PostgreSQL
Параметр max_connections в postgresql.conf устанавливает жёсткий верхний предел числа одновременных клиентских соединений, принимаемых сервером PostgreSQL, что делает его одним из наиболее критических параметров для администрирования базы данных и настройки производительности. Каждое соединение потребляет примерно 5–10 МБ разделяемой памяти, поэтому увеличение max_connections без тщательного планирования может исчерпать RAM и ухудшить общую производительность PostgreSQL. Для высоконагруженных систем администраторы баз данных обычно устанавливают max_connections в умеренное значение (100–200) и используют перед базой данных пулер соединений, например PgBouncer, который мультиплексирует множество соединений приложений на меньший пул реальных серверных процессов PostgreSQL. Изменение max_connections требует полного перезапуска сервера, поскольку PostgreSQL выделяет структуры разделяемой памяти для максимального числа соединений при запуске. Мониторинг текущего использования соединений через представление pg_stat_activity позволяет администраторам обнаружить исчерпание соединений до того, как это вызовет ошибки приложения.
Как это работает
max_connections мультиплексирует много app-уровневых соединений на несколько реальных Postgres-backend. Каждое соединение Postgres ест ~10MB RAM + backend-процесс; тысячи idle app-соединений вычерпывают сервер. PgBouncer (transaction-level pooling — дефолт и самый полезный) и PgCat — стандартные инструменты. App-уровневые пулы (HikariCP, pg-pool) держат сторону приложения. Комбинируйте оба слоя в серьёзном production.
Когда применять
PgBouncer — когда app pod × размер пула > max_connections Postgres. transaction-режим по дефолту; session — если приложение использует prepared statements, advisory lock или session GUC, которые должны жить. App-side pool — ~10-20 на worker; PgBouncer гасит всплески. Тестируйте pgbench -c <ожидаемая конкурентность> до запуска.
Типичные ошибки
Ловушки max_connections: забыли, что transaction-режим ломает prepared statements (PG 14+ имеет server-side cache, но проверьте драйвер); PgBouncer один поток на гигантском боксе (не масштабирует 32 ядра — несколько процессов или PgCat); нет мониторинга pool wait time (клиенты тихо блокируются на полном пуле). Читайте SHOW STATS PgBouncer.