El agotamiento de conexiones a base de datos en PHP suele manifestarse como errores intermitentes: algunas solicitudes fallan, otras se quedan esperando y el problema empeora en horas de carga alta. Aumentar el límite de conexiones puede aliviarlo, pero también puede trasladar la saturación al servidor de base de datos. La solución empieza por identificar qué recurso se agota y quién mantiene ocupadas las conexiones.
Reconoce los síntomas y delimita el fallo
Busca errores como «too many connections», fallos al abrir una conexión, tiempos de espera agotados o solicitudes que exceden el tiempo máximo de ejecución. Contrasta su frecuencia con el tráfico y con otros indicadores: latencia de la aplicación, uso de CPU y memoria, errores de la base de datos y duración de las solicitudes.
La diferencia entre carga alta y baja ofrece una primera pista. Si los errores aparecen durante picos y desaparecen al caer el tráfico, puede haber un límite de concurrencia. Si persisten con pocas solicitudes, investiga conexiones retenidas, procesos bloqueados, consultas prolongadas o una base de datos inaccesible. Confirma también si otros servicios comparten el mismo límite: PHP no necesariamente es el único consumidor.
Distingue conexiones agotadas de consultas lentas y bloqueos
Son problemas relacionados, pero no equivalentes. La conexión agotada ocurre cuando no hay cupo disponible para abrir otra. Una consulta lenta ocupa una conexión durante más tiempo y puede provocar el agotamiento al acumularse. Un bloqueo deja una consulta esperando a que otra transacción libere recursos. La indisponibilidad implica que la base de datos no puede aceptar o atender conexiones por una causa más amplia.
Examina el mensaje y el punto de fallo. Si la solicitud falla antes de ejecutar una consulta, revisa la creación de conexiones y el límite alcanzado. Si logra conectarse y luego tarda, inspecciona las consultas en curso, sus tiempos, esperas y transacciones abiertas. No concluyas que «faltan conexiones» sólo porque la aplicación responde despacio: aumentar el cupo no corrige una consulta costosa ni un bloqueo.
Relaciona la concurrencia de PHP con el límite de la base de datos
En el modelo habitual de PHP con procesos que atienden solicitudes, cada proceso puede necesitar una conexión mientras ejecuta trabajo con la base de datos. La demanda potencial depende de cuántos procesos pueden operar simultáneamente, de cuántas conexiones abre cada uno y de cuánto tiempo las conserva. En trabajos en segundo plano, comandos de consola y otros servicios también hay que contabilizar sus conexiones.
Haz una estimación conservadora del peor caso: multiplica la concurrencia máxima efectiva de cada grupo de procesos por las conexiones simultáneas que puede usar cada proceso y suma los consumidores que comparten la base de datos. Contrástala con el límite configurado y reserva margen para operaciones administrativas y variaciones de carga. No supongas que cada petición equivale siempre a una conexión: el ciclo de vida depende del cliente de base de datos, la configuración y el patrón de uso.
Revisa además cómo se distribuye la carga. Varias instancias de PHP pueden respetar sus límites locales y, aun así, exceder conjuntamente el cupo de la base de datos. El escalado horizontal aumenta la concurrencia potencial; no es una mitigación segura si no se recalcula el total de conexiones.
Mide desde los dos extremos
Correlaciona métricas de la aplicación y de la base de datos usando marcas de tiempo. En PHP, registra la duración de las solicitudes, los errores al conectar, los tiempos de espera y el número de procesos ocupados. En la base de datos, revisa conexiones activas y máximas, rechazos, consultas en ejecución, antigüedad de las sesiones y esperas disponibles en el motor.
Evita registrar credenciales, cadenas de conexión completas o datos sensibles de las consultas. Si el motor permite identificar sesiones y estados, úsalos para distinguir una conexión inactiva de una consulta activa o una transacción pendiente. Compara los registros de ambos lados: un pico de conexiones simultáneo a procesos PHP ocupados apunta a concurrencia; muchas sesiones antiguas o procesos inactivos sugieren retención; unas pocas consultas de larga duración pueden explicar que el cupo se consuma poco a poco.
La instrumentación debe permitir responder tres preguntas: cuántas conexiones se usan, cuánto duran y qué trabajo las mantiene ocupadas. Sin esa línea temporal, cambiar límites o activar conexiones persistentes introduce más variables y dificulta encontrar la causa.
Evalúa conexiones persistentes y de larga duración
Una conexión persistente puede reducir el coste de abrir conexiones repetidamente, especialmente cuando el entorno conserva procesos entre solicitudes. Sin embargo, una conexión que permanece asociada a un proceso también puede retener un cupo aunque no esté ejecutando consultas. Si hay muchos procesos o varias instancias, el conjunto de conexiones retenidas puede alcanzar el límite de la base de datos.
Comprueba el ciclo de vida real del proceso y del controlador antes de activarlas o desactivarlas. Verifica cómo se reutiliza la sesión y si la aplicación restablece el estado esperado entre solicitudes, como transacciones, variables de sesión o configuración específica de la conexión. Las conexiones persistentes no son un pool universal ni garantizan menor consumo; pruébalas bajo carga representativa y observa conexiones máximas, latencia y estado residual.
Mitiga en orden y con evidencia
- Limita la concurrencia. Ajusta los procesos de PHP o el paralelismo de los trabajadores para que la demanda simultánea sea compatible con el cupo compartido. Reduce la presión, aunque puede aumentar la cola y la latencia si la capacidad queda por debajo de la demanda sostenida.
- Libera recursos cuando ya no se necesitan. Cierra conexiones explícitamente si la biblioteca y el patrón de ejecución lo permiten, y evita conservarlas durante trabajo ajeno a la base de datos. Ten presente que cerrar una conexión persistente no necesariamente libera la conexión física del servidor: el resultado depende del controlador y del ciclo de vida del proceso. Revisa transacciones que permanezcan abiertas y rutas de error que no completen la limpieza.
- Reduce el tiempo de ocupación. Analiza consultas lentas, índices, volumen de resultados y transacciones. Optimizar una operación que retiene conexión mucho tiempo puede reducir la demanda simultánea sin elevar el límite.
- Ajusta límites sólo tras medir. Aumentar el máximo puede ser razonable si queda capacidad de CPU y memoria en la base de datos y el nuevo peor caso es sostenible. De lo contrario, permite que más trabajo se acumule y agrava la saturación.
Aplica un cambio cada vez, registra el estado anterior y define una condición de reversión. Si el sistema ya está afectado, reducir temporalmente la concurrencia puede ser más seguro que reiniciar todos los procesos a la vez, lo que podría crear un nuevo pico de conexiones.
Cuándo valorar un pool o proxy de conexiones
Un pool o proxy puede reutilizar conexiones físicas y controlar cuántas llegan al motor, lo que resulta útil cuando hay muchos procesos de aplicación con conexiones de vida corta. No elimina el trabajo simultáneo ni vuelve rápidas las consultas; introduce otra capa con capacidad, colas, límites y modos de operación propios.
Antes de adoptarlo, comprueba la compatibilidad con el motor, el controlador PHP, la autenticación, el uso de transacciones y el estado de sesión. Revisa cómo gestiona conexiones largas, reconexiones y fallos del proxy, y define métricas y procedimientos para operarlo. Valida con pruebas que representen la concurrencia real: una configuración que funciona en desarrollo puede comportarse de otra forma bajo presión.
Prepara la recuperación y evita recurrencias
Establece alertas para conexiones cercanas al límite, rechazos, duración de consultas y saturación de los procesos PHP. Añade una prueba de carga representativa que incluya instancias, trabajos en segundo plano y otros consumidores; comprueba el peor caso y no sólo el promedio. Mantén un procedimiento operativo que indique qué medir, cómo limitar concurrencia, quién puede cambiar el cupo y cuándo revertir.
Tras recuperar el servicio, revisa la secuencia que precedió al incidente: cambios de tráfico, despliegues, consultas nuevas, crecimiento de procesos o fallos de limpieza. El objetivo es vincular causa y efecto con datos. Si las métricas muestran conexiones retenidas, corrige su ciclo de vida; si domina la duración de consultas, optimízalas; si la concurrencia legítima supera la capacidad, dimensiona y limita con un presupuesto de conexiones explícito.
