Что означает ошибка Too many connections
MySQL отклоняет новое подключение с ошибкой Too many connections, когда число активных сессий достигает лимита max_connections. Сервер резервирует одно дополнительное подключение для пользователя с правом SUPER, поэтому администратор обычно может зайти и разобраться, даже когда обычные клиенты уже получают отказ.
Ошибка редко означает, что сайту действительно нужно больше соединений: чаще всего это симптом утечки — приложение открывает подключения быстрее, чем закрывает.
Как посмотреть текущий лимит и нагрузку
Прежде чем менять лимит, стоит понять, сколько соединений реально открыто и кто их держит.
SHOW VARIABLES LIKE 'max_connections';
SHOW STATUS LIKE 'Threads_connected';
SHOW STATUS LIKE 'Max_used_connections';
SHOW PROCESSLIST;Столбец Time в SHOW PROCESSLIST показывает, сколько секунд сессия находится в текущем состоянии. Если у многих строк состояние Sleep и Time исчисляется сотнями секунд, это почти всегда утечка соединений на стороне приложения.
Ключевые параметры лимитов соединений
| Параметр | Типичное значение | За что отвечает |
|---|---|---|
| max_connections | 151–500 | максимум одновременных подключений к серверу |
| wait_timeout | 28800 | секунд простоя, после которых сервер закрывает неактивную сессию |
| interactive_timeout | 28800 | то же самое для интерактивных клиентов, например mysql CLI |
Снижение wait_timeout до 60–120 секунд для веб-нагрузки помогает закрывать зависшие соединения быстрее, не дожидаясь стандартных восьми часов. Подбор остальных параметров описан в статье про настройку my.cnf.
Откуда берутся утечки соединений в приложении
- Скрипт открывает соединение с базой и завершается с ошибкой до вызова close — соединение виснет до истечения wait_timeout.
- Пул соединений настроен с большим размером, чем реально нужно приложению, и держит лишние сессии открытыми про запас.
- Долгий SELECT без LIMIT блокирует поток на минуты, а новые запросы открывают новые подключения поверх старых.
- Несколько копий приложения (воркеры, крон-задачи) держат свои пулы, и суммарно они превышают лимит сервера.
Как настроить пул соединений правильно
Пул соединений решает проблему только тогда, когда его размер согласован с лимитом сервера, а не выбран наугад.
# Пример для приложения с несколькими воркерами:
# 4 воркера x pool_size 20 = 80 соединений
# max_connections на сервере должен быть заметно больше 80
max_connections = 200Правило простое: суммарный размер всех пулов на всех воркерах приложения должен быть меньше max_connections с запасом на служебные подключения — мониторинг, бэкапы, ручные сессии администратора.
Экстренные меры при переполнении лимита
Если ошибка Too many connections уже идёт на проде, действовать нужно быстро и по порядку.
- Зайти под учётной записью с правом SUPER — для неё зарезервировано отдельное подключение.
- Через SHOW PROCESSLIST найти сессии с самым большим Time в состоянии Sleep и завершить их командой KILL.
- Временно поднять max_connections через SET GLOBAL, не дожидаясь перезапуска сервера.
- Проверить лог медленных запросов, чтобы найти запрос, который держит соединения дольше всех.
SET GLOBAL max_connections = 300;
KILL 12345;Итог: чек-лист по ошибке Too many connections
- Проверить текущий max_connections и реальное число подключений через Threads_connected.
- Найти зависшие сессии в SHOW PROCESSLIST по большому значению Time.
- Снизить wait_timeout для веб-нагрузки, если сессии копятся в Sleep.
- Свести суммарный размер пулов приложения с лимитом сервера.
- При масштабировании читающей нагрузки рассмотреть ProxySQL вместо роста max_connections до бесконечности.