Base de datos
La aplicación empieza a dar errores de conexión bajo carga. El servidor ha llegado a max_connections y no acepta más.
Subir max_connections es la reacción inmediata y casi nunca es la solución: cada conexión consume memoria, y el límite suele estar tapando conexiones que nadie cierra.
En el orden en que lo miramos nosotros. No es un ranking de frecuencia: no publicamos estadísticas que no hemos medido.
Hay conexiones ociosas acumuladas, casi siempre por un pool mal dimensionado o por código que no devuelve la conexión.
Comprobar
mysql -e "SELECT command, count(*) FROM information_schema.processlist GROUP BY command ORDER BY 2 DESC;"Corregir
# Corregir el pool de la aplicación. Como medida inmediata, bajar el tiempo
# que una conexión puede estar ociosa:
# wait_timeout = 300Hay consultas lentas que mantienen conexiones ocupadas mucho más tiempo del debido.
Comprobar
mysql -e "SELECT id, user, time, state, LEFT(info,80) FROM information_schema.processlist WHERE command <> 'Sleep' ORDER BY time DESC LIMIT 10;"Corregir
# Revisar el plan de la consulta lenta y sus índices:
# EXPLAIN SELECT ...;El límite es genuinamente bajo para la carga real.
Comprobar
mysql -e "SHOW VARIABLES LIKE 'max_connections'; SHOW STATUS LIKE 'Max_used_connections';"Corregir
# Subirlo comprobando antes que hay memoria para ello:
# max_connections = 300Max_used_connections es el máximo alcanzado desde el último arranque. Si está pegado a max_connections, el límite se está tocando de verdad; si está muy por debajo, el problema es un pico puntual o conexiones que no se cierran.
Los comandos de esta página se ejecutan en tu servidor y algunos modifican la configuración: léelos antes de pegarlos. Las rutas y los nombres de servicio varían entre distribuciones. Así se elabora este catálogo.
Soporte Linux y DevOps en español