Исчерпание подключений к базе данных в PHP обычно проявляется периодическими ошибками: одни запросы завершаются с ошибкой, другие ждут, а в часы пик проблема усугубляется. Повышение лимита подключений может временно помочь, но при этом перегрузка может переместиться на сервер базы данных. Решение начинается с определения того, какой ресурс исчерпан и что удерживает подключения занятыми.
Распознайте симптомы и локализуйте сбой
Ищите ошибки вроде «too many connections», сбои при открытии подключения, тайм-ауты или запросы, превышающие максимальное время выполнения. Сопоставьте частоту ошибок с трафиком и другими показателями: задержкой приложения, использованием CPU и памяти, ошибками базы данных и длительностью запросов.
Разница между высокой и низкой нагрузкой — первая подсказка. Если ошибки появляются в пиковые периоды и исчезают при снижении трафика, возможно, достигнут предел конкурентности. Если они сохраняются и при небольшом количестве запросов, проверьте удерживаемые подключения, заблокированные процессы, долгие запросы или недоступность базы данных. Также выясните, используют ли этот же лимит другие сервисы: PHP может быть не единственным потребителем.
Отличайте исчерпание подключений от медленных запросов и блокировок
Эти проблемы связаны, но не тождественны. Исчерпание подключений возникает, когда нет свободного слота для открытия нового подключения. Медленный запрос дольше занимает подключение и при накоплении таких запросов может привести к исчерпанию подключений. При блокировке запрос ждёт, пока другая транзакция освободит ресурсы. Недоступность означает, что база данных не может принимать или обслуживать подключения по более общей причине.
Изучите сообщение об ошибке и место сбоя. Если запрос завершается с ошибкой до выполнения запроса к базе данных, проверьте создание подключений и достигнутый лимит. Если подключение устанавливается, но затем возникает задержка, изучите выполняющиеся запросы, их длительность, ожидания и открытые транзакции. Не делайте вывод, что «не хватает подключений», только потому, что приложение отвечает медленно: повышение лимита не исправит ресурсоёмкий запрос или блокировку.
Сопоставьте конкурентность PHP с лимитом базы данных
В распространённой модели PHP, где запросы обслуживаются процессами, каждому процессу может понадобиться подключение во время работы с базой данных. Потенциальная потребность зависит от числа процессов, которые могут работать одновременно, количества открываемых каждым процессом подключений и времени, в течение которого они удерживаются. Также учитывайте подключения фоновых задач, консольных команд и других сервисов.
Консервативно оцените наихудший случай: умножьте максимальную фактическую конкурентность каждой группы процессов на число подключений, которые каждый процесс может использовать одновременно, и прибавьте потребление остальных клиентов общей базы данных. Сравните результат с настроенным лимитом и оставьте запас для административных операций и колебаний нагрузки. Не исходите из того, что каждый запрос всегда соответствует одному подключению: жизненный цикл зависит от клиента базы данных, настроек и схемы использования.
Также проверьте распределение нагрузки. Несколько экземпляров PHP могут соблюдать локальные лимиты и всё же совместно превысить лимит базы данных. Горизонтальное масштабирование повышает потенциальную конкурентность и не является безопасным способом смягчения проблемы, если не пересчитать общее количество подключений.
Измеряйте показатели с обеих сторон
Сопоставляйте метрики приложения и базы данных по временным меткам. В PHP записывайте длительность запросов, ошибки подключения, тайм-ауты и число занятых процессов. В базе данных проверяйте количество активных и максимальное количество подключений, отказы, выполняющиеся запросы, возраст сессий и доступные в СУБД данные об ожиданиях.
Не записывайте учётные данные, полные строки подключения или конфиденциальные данные запросов. Если СУБД позволяет определять сессии и их состояние, используйте эти сведения, чтобы отличать неактивное подключение от выполняющегося запроса или ожидающей транзакции. Сопоставьте журналы с обеих сторон: одновременный всплеск подключений и занятых процессов PHP указывает на высокую конкурентность; множество старых сессий или простаивающих процессов может свидетельствовать об удержании подключений; несколько долгих запросов могут объяснять постепенное исчерпание лимита.
Инструментирование должно помочь ответить на три вопроса: сколько используется подключений, как долго они заняты и какая работа их удерживает. Без такой временной шкалы изменение лимитов или включение постоянных подключений добавит новые переменные и затруднит поиск причины.
Оцените постоянные и долгоживущие подключения
Постоянное подключение может снизить затраты на многократное открытие подключений, особенно если среда сохраняет процессы между запросами. Однако подключение, остающееся связанным с процессом, может занимать слот, даже когда запросы не выполняются. При большом количестве процессов или экземпляров совокупное число удерживаемых подключений может достичь лимита базы данных.
Прежде чем включать или отключать постоянные подключения, проверьте фактический жизненный цикл процесса и драйвера. Убедитесь, как повторно используется сессия и сбрасывает ли приложение состояние, которое должно быть восстановлено между запросами, например транзакции, переменные сессии или параметры подключения. Постоянные подключения — не универсальный пул и не гарантия меньшего потребления; тестируйте их под репрезентативной нагрузкой и отслеживайте максимальное число подключений, задержку и остаточное состояние.
Снижайте нагрузку поэтапно и на основании данных
- Ограничьте конкурентность. Настройте число процессов PHP или параллелизм обработчиков так, чтобы одновременная потребность соответствовала общему лимиту. Это снижает нагрузку, хотя при недостаточной для постоянной нагрузки пропускной способности может увеличиться очередь и задержка.
- Освобождайте ресурсы, когда они больше не нужны. Явно закрывайте подключения, если это допускают библиотека и схема выполнения, и не удерживайте их во время работы, не связанной с базой данных. Помните, что закрытие постоянного подключения не обязательно освобождает физическое подключение на сервере: результат зависит от драйвера и жизненного цикла процесса. Проверьте, не остаются ли открытыми транзакции и выполняется ли очистка при ошибках.
- Сократите время занятия подключения. Проанализируйте медленные запросы, индексы, объём результатов и транзакции. Оптимизация операции, которая долго удерживает подключение, может снизить одновременную потребность без повышения лимита.
- Меняйте лимиты только после измерений. Повышение максимума может быть оправдано, если у базы данных есть запас CPU и памяти, а новый наихудший сценарий устойчив. В противном случае это позволит накопиться большему объёму работы и усилит перегрузку.
Вносите по одному изменению за раз, фиксируйте исходное состояние и определите условие отката. Если система уже испытывает проблемы, временно снизить конкурентность может быть безопаснее, чем одновременно перезапускать все процессы: это может вызвать новый всплеск подключений.
Когда стоит рассмотреть пул или прокси подключений
Пул или прокси может повторно использовать физические подключения и контролировать, сколько подключений поступает в СУБД. Это полезно, когда у приложения много процессов с короткоживущими подключениями. Такой подход не устраняет одновременную работу и не ускоряет запросы: он добавляет ещё один уровень со своей пропускной способностью, очередями, лимитами и режимами работы.
Перед внедрением проверьте совместимость с СУБД, драйвером PHP, аутентификацией, использованием транзакций и состоянием сессии. Изучите, как прокси обрабатывает долгие подключения, переподключения и сбои, и определите метрики и процедуры эксплуатации. Проведите тесты, отражающие фактическую конкурентность: конфигурация, работающая в среде разработки, может вести себя иначе под нагрузкой.
Подготовьтесь к восстановлению и предотвращайте повторение
Настройте оповещения о приближении числа подключений к лимиту, отказах, длительности запросов и перегрузке процессов PHP. Добавьте репрезентативный нагрузочный тест, учитывающий экземпляры, фоновые задачи и других потребителей; проверьте наихудший сценарий, а не только средние показатели. Подготовьте инструкцию для эксплуатации: что измерять, как ограничивать конкурентность, кто вправе менять лимит и когда выполнять откат.
После восстановления сервиса изучите события, предшествовавшие инциденту: изменения трафика, релизы, новые запросы, увеличение числа процессов или сбои очистки. Цель — установить причинно-следственную связь на основании данных. Если метрики показывают, что подключения удерживаются, исправьте их жизненный цикл; если преобладает длительность запросов, оптимизируйте их; если допустимая конкурентность превышает возможности системы, рассчитайте ресурсы и установите ограничения на основе явного бюджета подключений.
