Железо и софт • 06.06.2026
PostgreSQL выдает ошибку FATAL too many clients already как исправить лимиты соединений
Развернул бэкенд-приложение на Node.js в связке с базой данных PostgreSQL на Windows 11. Во время проведения нагрузочного тестирования и имитации высокой активности пользователей сервер внезапно упал, а в консоль посыпались критические логи сбоя: «FATAL: sorry, too many clients already» или «FATAL: remaining connection slots are reserved for non-replication superuser connections». Теперь даже утилита pgAdmin и консольный клиент psql отказываются подключаться к СУБД, намертво блокируя доступ к таблицам. Подскажите, из-за чего наступает этот ступор пула соединений, как принудительно выгнать зависшие спящие сессии из памяти и правильно настроить лимиты в конфигурационных файлах?
Ответы (5)
Дмитрий DBA
Здорово! Ты поймал классическую проблему утечки соединений (connection leak) на стороне бэкенда. По умолчанию в Postgres параметр max_connections жестко зажат на отметке 100 слотов. Твое приложение на Node.js при каждом микро-запросе к базе открывает новый сетевой сокет, но забывает корректно закрывать его после получения данных (вызова метода client.end() или release()). В итоге порты остаются открытыми, а процессы уходят в спящий статус "idle". Когда лимит забивается под сотую отметку, СУБД активирует защиту, оставляет 3 резервных слота чисто для администратора (superuser), а все остальные входящие пакеты и запросы pgAdmin наглухо отсекает.
Сергей Девопс
Чтобы оперативно вернуть СУБД к жизни без полной жесткой перезагрузки всей службы, нужно зайти под админом и принудительно погасить мертвые процессы по шагам:
1. Откройте консоль командной строки Windows от имени администратора и запустите psql, принудительно указав суперпользователя: `psql -U postgres`.
2. Введите ваш мастер-пароль. Благодаря резервным слотам система пропустит вас в консоль.
3. Выведите список всех зависших сессий, которые висят в режиме сна больше минуты, выполнив SQL-запрос: `SELECT pid, state, query FROM pg_stat_activity WHERE state = 'idle';`.
4. Найдите идентификаторы процессов (PID) мешающих сессий и принудительно убейте их системной командой: `SELECT pg_terminate_backend(PID);` (вместо PID подставьте числовой номер, например 4512).
5. Чтобы очистить вообще все спящие соединения приложения разом, выполните: `SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE state = 'idle' AND usename != 'postgres';`. Лимиты моментально очистятся.
Михаил Архитектор
Ребята, простое тупое увеличение лимита max_connections в конфигурационном файле до 500 или 1000 — это путь к жесткому проседанию производительности и процессора. Постгрес под каждое новое соединение выделяет изолированный тяжелый процесс ОС, который начинает жрать кэш памяти и конкурировать за ядра CPU. Правильный архитектурный подход для борьбы с "too many clients" — это установка легковесного пуллера соединений, например PgBouncer. Он будет удерживать всего 10-20 реальных постоянных мостов с базой, а со стороны приложения сможет без проблем переваривать тысячи одновременных виртуальных веб-запросов, выстраивая их в очередь.
Никита Систем
Если сервер располагает достаточным объемом ОЗУ и вам необходимо расширить базовые лимиты слотов СУБД напрямую, выполните корректировку по инструкции:
1. Перейдите в каталог данных вашей установленной СУБД, стандартный путь на Windows: `C:Program FilesPostgreSQLверсияdata`.
2. Найдите файл `postgresql.conf`, кликните правой кнопкой мыши и откройте его через обычный Блокнот от имени администратора.
3. Нажмите сочетание клавиш Ctrl + F, найдите строку `max_connections` и измените дефолтное значение со 100 на более высокое, например `250`.
4. Чуть ниже отыщите параметр `shared_buffers` и соразмерно увеличьте его (рекомендуется выделить около 25% от всей оперативной памяти вашего ПК для кэша индексов).
5. Нажмите Сохранить, закройте Блокнот. Откройте диспетчер служб Windows (`services.msc`), найдите службу `postgresql` и нажмите Перезапустить для применения конфигураций.
Роман Кодер
Чтобы СУБД сама автоматически защищалась от забывчивых разработчиков и кривых скриптов бэкапа, настройте жесткие тайм-ауты на стороне ядра. Откройте файл `postgresql.conf`, найдите и раскомментируйте строчку `idle_in_transaction_session_timeout`. Выставите там значение `30000` (это 30 секунд). Теперь, если какое-то соединение зависнет внутри открытой транзакции и уснет, база сама принудительно закроет этот сокет, предотвращая ошибку переполнения пула.