Los errores relacionados con max_user_connections y Too many connections indican que MariaDB o MySQL alcanzó un límite de conexiones simultáneas, pero no representan exactamente el mismo problema. Identificar qué límite se agotó permite evitar cambios que solamente oculten la causa.
Una conexión es una sesión abierta entre una aplicación y el servidor de base de datos. Puede estar ejecutando una consulta, esperando una respuesta, permaneciendo inactiva o retenida por un proceso. El problema no depende únicamente de la cantidad de visitas: una aplicación defectuosa puede generar muchas conexiones con poco tráfico.
Qué es max_connections
max_connections establece cuántas conexiones de clientes puede aceptar simultáneamente el servidor de base de datos. Es un límite global: incluye las sesiones de distintas cuentas y aplicaciones alojadas en esa instancia.
Cuando el servidor alcanza ese máximo, las conexiones nuevas normalmente reciben el mensaje Too many connections. MariaDB reserva una posibilidad administrativa para usuarios con privilegios especiales, de modo que un administrador pueda ingresar y diagnosticar el problema, pero una cuenta de hosting común no utiliza esa reserva.
Qué es max_user_connections
max_user_connections limita las conexiones simultáneas que puede abrir una misma cuenta de base de datos. Si un usuario alcanza ese valor, sus nuevas conexiones son rechazadas aunque el servidor todavía tenga capacidad para otros usuarios.
El límite puede definirse globalmente o específicamente para una cuenta. En hosting compartido, esta protección evita que una sola aplicación ocupe todas las conexiones disponibles y afecte a los demás clientes.
Diferencia principal
- max_connections: capacidad simultánea global del servidor MariaDB o MySQL.
- max_user_connections: capacidad simultánea de una cuenta concreta de base de datos.
El texto exacto del error puede incluir el usuario afectado o indicar explícitamente que se superó max_user_connections. Conservá el mensaje completo: recortar solamente “Too many connections” puede eliminar la información que diferencia ambos casos.
No lo confundas con límites por hora
MySQL y MariaDB también pueden aplicar límites de conexiones por hora, consultas por hora o actualizaciones por hora a una cuenta. Esos controles cuentan actividad durante un período, mientras que max_user_connections mide sesiones abiertas al mismo tiempo.
Una aplicación puede realizar miles de conexiones cortas durante una hora sin superar el límite simultáneo, o alcanzar el límite simultáneo con pocas conexiones que permanecen abiertas demasiado tiempo.
Por qué una aplicación abre demasiadas conexiones
- Consultas lentas que retienen sesiones mientras procesan datos.
- Conexiones que el código no cierra o no devuelve correctamente al pool.
- Un pool configurado con demasiadas conexiones por proceso.
- Picos legítimos de visitantes o tareas internas.
- Procesos Cron que comienzan nuevamente antes de terminar.
- Plugins, módulos o integraciones que consultan en cada solicitud.
- Bots, ataques o tráfico automatizado que alcanza rutas dinámicas.
- Bloqueos entre transacciones que hacen que otras consultas esperen.
- Un servidor de base de datos con recursos insuficientes o sobrecargado.
Conexiones activas e inactivas
Una conexión marcada como inactiva no siempre representa un error. Las aplicaciones pueden mantener un conjunto de sesiones preparado para reducir el costo de reconectar. El problema aparece cuando el tamaño del pool no corresponde a la capacidad del servidor o cuando se crean nuevos pools por cada proceso.
También hay que revisar el tiempo durante el cual una sesión inactiva permanece abierta. Reducirlo agresivamente puede romper aplicaciones o aumentar reconexiones; dejarlo demasiado alto puede mantener sesiones innecesarias. El valor correcto depende del patrón de uso.
Cómo diagnosticar en un servidor administrado
El administrador debe revisar, idealmente durante el incidente:
- Cantidad total de conexiones y máximo observado.
- Usuarios y hosts que abren más sesiones.
- Estados de las conexiones y tiempo acumulado.
- Consultas que se ejecutan o esperan.
- Bloqueos y transacciones abiertas.
- Uso de memoria, CPU y disco.
- Registros de consultas lentas y errores.
La lista de procesos es una fotografía del momento. Si se revisa después de que el pico terminó, puede parecer normal. Por eso son importantes las métricas históricas y la hora exacta del error.
Qué información enviar al soporte
En un hosting compartido, normalmente no podés consultar variables globales ni ver sesiones de otras cuentas. Enviá:
- Mensaje de error completo.
- Fecha y hora con zona horaria.
- Dominio y URL donde ocurrió.
- Acción que estaba realizando el usuario.
- Frecuencia y duración aproximada.
- Cambios recientes en plugins, código o tareas Cron.
No incluyas contraseñas de bases de datos. Podés seguir la guía para contactar al soporte de Atlántica Digital.
¿Aumentar el límite soluciona el problema?
No necesariamente. Aumentar max_connections permite más sesiones, pero cada una puede consumir memoria y otros recursos. Un valor mayor en un servidor sin capacidad suficiente puede transformar un rechazo controlado en falta de memoria, intercambio a disco o caída general.
Aumentar max_user_connections tampoco corrige consultas lentas, fugas de conexiones o pools desproporcionados. Puede ser apropiado cuando la carga es legítima, el servidor tiene margen y las métricas demuestran que la aplicación está bien diseñada. Debe hacerse después del diagnóstico, no como primera reacción.
Acciones del lado de la aplicación
- Actualizá el CMS, framework y controladores de base de datos.
- Desactivá temporalmente plugins o módulos sospechosos en un entorno controlado.
- Revisá que las conexiones se cierren o se devuelvan al pool.
- Ajustá el tamaño del pool según procesos, instancias y límite total.
- Reducí la duración de consultas mediante índices y cambios de código.
- Aplicá caché cuando los datos no necesiten consultarse en cada visita.
- Evitá trabajos masivos durante períodos de mayor tráfico.
La guía sobre cómo optimizar una base de datos MySQL desarrolla el análisis de consultas, índices, estadísticas y tablas.
Revisá tareas Cron y procesos simultáneos
Una tarea que tarda diez minutos pero se inicia cada minuto puede acumular varias ejecuciones y conexiones. Revisá frecuencia, duración y mecanismos que evitan solapamientos.
El artículo sobre Cron Jobs en cPanel explica cómo elegir intervalos coherentes y controlar la salida. No elimines una tarea sin identificar primero qué función cumple dentro de la aplicación.
Tráfico automatizado y protección
Los bots pueden generar muchas solicitudes dinámicas que llegan hasta PHP y MySQL. Una CDN, caché de página, limitación de solicitudes o reglas de seguridad puede reducir esa carga antes de que alcance la base.
Sin embargo, no bloquees visitantes legítimos solamente para ocultar una consulta ineficiente. Combiná protección de tráfico con optimización de la aplicación.
En hosting compartido, VPS y servidor dedicado
En hosting compartido los límites protegen la estabilidad general y no suelen modificarse por cuenta sin evaluación. Si la aplicación los alcanza de forma frecuente después de optimizarla, puede necesitar un plan con más recursos o una arquitectura diferente.
En un VPS o dedicado tenés mayor control, pero también responsabilidad sobre memoria, configuración y monitoreo. Antes de aumentar conexiones, estimá el consumo por sesión y reservá capacidad para el sistema, el servidor web, PHP y los demás servicios.
Qué no conviene hacer
- Reiniciar MariaDB repetidamente sin investigar la causa.
- Finalizar conexiones al azar en un servidor de producción.
- Copiar valores de configuración de otro servidor.
- Aumentar todos los límites al máximo.
- Ignorar errores intermitentes porque el sitio volvió a responder.
- Compartir credenciales o registros con datos sensibles.
Secuencia recomendada
- Guardá el mensaje completo y la hora.
- Determiná si el límite es global, por usuario o por período.
- Identificá usuarios, procesos y consultas responsables.
- Corregí consultas, pools, tareas y tráfico innecesario.
- Medí nuevamente en una carga representativa.
- Ajustá límites solamente si existe capacidad y una necesidad demostrada.
La documentación oficial de MariaDB sobre cómo manejar Too many connections y los límites de cuenta descritos en CREATE USER confirma la diferencia entre capacidad global y conexiones simultáneas por usuario. El objetivo del diagnóstico es corregir la causa y mantener estabilidad, no solamente mover el límite.
