systemadmin.es > DBA > Dimensionar max_connections y max_user_connections

Dimensionar max_connections y max_user_connections

Los parámetros que limitan el número de conexiones a MySQL son max_connections y max_user_connections. Gracias a ellas podemos hasta cierto punto controlar el MySQL para evitar que devore los recursos del sistema.

  • El parámetro max_connections define el número global de conexiones permitidas (sumando todos los usuarios), pero siempre se reserva una extra para la conexión de un usuario SUPER (root). De esta forma si algún proceso satura el MySQL de conexiones aún queda otra disponible para que el usuario root pueda ver quien lo ha causado (y arreglarlo mediante KILL)
  • Por otro lado tenemos el parámetro max_user_connections que permite limitar el número de conexiones por usuario. En el caso que dejemos el valor a cero, indica que no exista límite por usuario.

La gracia esta en saber ajustar estos dos valores. Evidentemente se puede razonar que si existe la posibilidad que se creen 100 procesos apache y todos ellos realizan una petición a la base de datos, el max_connections debería estar a 100.

Este razonamiento es perfectamente válido, pero en el caso que exista algún problema en la base de datos, por ejemplo un simple mysqldump de una tabla, las conexiones se quedaran a la espera y se irán acumulando. Por el efecto bola de nieve, al tener conexiones acumuladas las que no tengan nada que ver con la tabla bloqueada irán más lentas acumulándose también.

En MySQL no existe una forma para gestionar los recursos (IO, CPU, RAM…) por conexión o usuario, por lo que podemos acabar con el servidor bloqueado muy fácilmente.

Por lo tanto, para ajustar estos valores siempre deberíamos empezar por valores bajos e ir ajustando. Cada aplicación es diferente, pero definir unos límites de conexiones demasiado altos acabaremos con más problemas de los que intentamos evitar dejando el valor alto.

Por citar un ejemplo, por cada millón de páginas vistas al día, el número de threads conectados al MySQL suele ser entre 10 y 15. A partir de 25 ya suele indicar problemas de algún tipo, por lo que un valor entre 30 y 40, para permitir un crecimiento sano, puede ayudar a contener un problema a que sature tanto la base de datos como los frontales de peticiones que no acaban. Evidentemente, si el problema es localizado a una parte de la aplicación, el resto podría seguir funcionando si no se saturan los equipos.

Deja un comentario:

XHTML - Tags permitidos:<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>