Base de datos

ERROR 1040 (HY000): Too many connections

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.

Qué comprobar, y en qué orden

En el orden en que lo miramos nosotros. No es un ranking de frecuencia: no publicamos estadísticas que no hemos medido.

  1. 1

    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 = 300
  2. 2

    Hay 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 ...;
  3. 3

    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 = 300

Un detalle que ahorra tiempo

Max_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.