Ошибка Too many connections в MariaDB означает, что новое подключение отклонено из-за исчерпания доступных соединений. Сначала сопоставьте лимит с текущей занятостью и выясните, какое приложение удерживает подключения; повышение max_connections без этой проверки может лишь отложить повторный отказ.
Сайт при этом может отдавать серверную ошибку только на страницах, которым нужна БД, а кешированная главная продолжит открываться. Зафиксируйте время сбоя и точную ошибку приложения.
1. Подтвердите лимит на нужном сервере
Через уже настроенный защищённый административный доступ выполните команды чтения:
SELECT @@hostname, @@port, VERSION();
SHOW GLOBAL VARIABLES LIKE 'max_connections';
SHOW GLOBAL STATUS
WHERE Variable_name IN (
'Threads_connected', 'Threads_running',
'Max_used_connections', 'Connection_errors_max_connections',
'Uptime'
);Сверьте узел с конфигурацией приложения. Если подключиться уже нельзя, используйте предусмотренный административный канал или обратитесь к хостеру; не выдавайте приложению расширенные права ради обхода лимита.
Читайте показатели MariaDB вместе:
Threads_connected— открытые клиентские соединения сейчас.Threads_running— соединения, выполняющие команды, а не ожидающие следующую; показатель также может учитывать внутренние потоки.Max_used_connections— исторический максимум одновременных соединений, а не текущая нагрузка.- Рост
Connection_errors_max_connectionsмежду замерами подтверждает новые отказы из-за общего лимита.
Повторите замер через короткий интервал и запишите время. Учтите перезапуски и сброс статистики. Если сообщение называет max_user_connections, администратор должен проверить отдельную квоту учётной записи: свободные места в общем лимите её не отменяют.
2. Найдите потребителя соединений
Снимите список подключений во время проблемы:
SHOW FULL PROCESSLIST;В справке SHOW PROCESSLIST описаны поля User, Host, db, Command, Time, State и Info. Без права PROCESS видны только соединения своей учётной записи, поэтому небольшой список ещё не доказывает низкую общую занятость.
Сопоставьте пользователя, узел и базу с веб-приложением, очередью, импортом и расписанием. Для TCP поле Host содержит ещё и клиентский порт: разные порты не означают разные серверы. Полный SQL может содержать секреты и персональные данные; передавайте только обезличенные типы запросов, состояния и количество соединений.
Много ожидающих соединений
Sleep означает ожидание следующей команды. Это не доказательство утечки: пул может намеренно хранить свободные подключения. Проверьте, укладывается ли их число в настройки пулов и уменьшается ли после завершения нагрузки.
Посчитайте бюджет всех экземпляров: веб-процессы, фоновые работники, импорты и административные задачи делят один лимит. Масштабирование увеличивает суммарный бюджет даже при прежних настройках каждого пула.
Много долгих запросов или ожиданий
Сравните повторные снимки: какие команды остаются, как меняются Time и State. Затем сопоставьте их с медленными запросами, блокировками и ресурсами сервера. Соединения могут накапливаться потому, что работа стала дольше, а не потому, что пришло больше посетителей.
Проверьте последние релизы, запуск тяжёлого отчёта, рост числа работников и повторные попытки подключения. Если одновременно заняты обработчики PHP, используйте отдельный разбор очереди PHP-FPM: увеличение их числа способно усилить давление на базу.
3. Освободите ресурс по найденной причине
Начните с управляемого ограничения источника: приостановите некритичный импорт, уменьшите параллелизм работников или исправьте повторные попытки без паузы. Возвращайте нагрузку постепенно, наблюдая за соединениями и ошибками приложения.
Не завершайте все Sleep автоматически: ожидающая сессия может держать незавершённую транзакцию. Администратор должен установить владельца и последствия; по документации KILL, завершение соединения откатывает активную транзакцию, а остановка только запроса оставляет её активной.
Перезапуск БД обрывает клиентов и лишает текущего диагностического снимка. Одновременное переподключение пулов может вернуть отказ.
4. Решите, нужно ли повышать max_connections
Руководство MariaDB допускает увеличение лимита, когда система работает нормально и ей действительно требуется больше подключений. Сначала исключите медленные запросы и другие узкие места.
Оцените память под рабочей нагрузкой, CPU, диски и системные ограничения. Нельзя считать безопасный предел делением всей RAM на условный размер соединения: расход зависит от выполняемой работы и остальных служб.
Изменение согласуйте с суммарным бюджетом пулов, запасом для обслуживания и планом возврата. Сокращение wait_timeout тоже требует согласования с приложением: сервер может закрыть простаивающее соединение, которое пул ещё считает пригодным. Область действия и поведение параметров сверяйте со справкой установленной версии.
5. Проверьте результат на той же нагрузке
Повторите безопасный сценарий, который вызывал сбой, без реальных оплат и повторного создания заказов. Убедитесь, что новые отказы не накапливаются, подключения освобождаются, время ответа восстановилось, а память и диски не стали новым ограничением.
Внешний мониторинг Web-Puls помогает сопоставить HTTP-ошибки и задержки публичного URL со временем события, но не читает соединения MariaDB и не устанавливает их источник. Один успешный ответ кешированной страницы не подтверждает восстановление работы с БД.
Если источник накопления неясен, отправьте заявку на диагностику. Укажите публичный URL, время с часовым поясом, точный код ошибки, обезличенные показатели и последние изменения; формат и стоимость работ согласуют до начала, пароли и полный SQL передавать не нужно.