Tutoriales y guías
7 minutos
Diagnóstico de rendimiento en entornos de bases de datos MySQL
No es extraño recibir una llamada o un correo electrónico diciendo: “La base de datos va lenta… Soluciónalo rápido!”. Y se dará por sentado que ya de antemano sabes el motivo por el que va lento, o qué es lo que se ha podido cambiar a nivel de aplicación.
Los problemas en MySQL dependen de muchos factores, y normalmente tenemos poco tiempo para analizar o investigar, máxime si estamos en mitad de una severidad. ¿Dónde tendría que poner mi atención para determinar la causa raíz del problema?
Este artículo está enfocado a alguien con pocos conocimientos en la monitorización de servidores con el objetivo de dotarle de unas primeras estrategias de revisión que permitan acotar el origen de la anomalía.
Cuellos de botella
Un paso obligado en esta revisión es el diagnóstico de posibles cuellos de botella, ejecutando una serie de comandos que nos permite tener una visión global de lo que está sucediendo en un instante concreto, de modo que podamos determinar qué recursos son los más comprometidos: CPU, memoria, I/O a disco, etc.
Para ello podemos utilizar una serie de herramientas de consola que normalmente suelen estar por defecto instaladas en las distribuciones Linux. Añado como hipervínculo los enlaces a la documentación de cada herramienta.
En primer lugar podemos usar la herramienta ‘top’ para comprobar si hay algún proceso que está acaparando gran parte del uso de CPUs. Siendo así, habría que determinar la forma de que dicha aplicación use menos CPU, o decidir moverla a un servidor dedicado. Si fuera el propio MySQL el que está haciendo el uso intensivo de CPU, sería conveniente ver qué está ocurriendo en el motor de base de datos; quizá se trata de algún usuario lanzando alguna consulta mal implementada. Si no encontramos ninguna evidencia de problemas en la CPU, tendríamos la certeza de que el problema está en otro sitio.
A continuación, podemos ejecutar el comando vmstat en intervalos determinados de tiempo. Conviene ejecutarlo durante al menos 3 minutos de modo que podamos identificar alguna métrica y patrón que nos pueda ofrecer un indicio de un posible problema de memoria, CPU o I/O a disco.
Por último, podemos ejecutar iostat; igualmente en intervalos de 5 o 10 segundos y durante varios minutos. Dado que la información que devuelve es extensa, se recomienda filtrar el resultado de modo que nos quedemos únicamente con los registros del disco donde está instalado el MySQL.
En este sentido, nos centraríamos en los valores de %util y tps con el fin de obtener información de qué procesos son los que pudieran estar provocando problemas en el servidor.
Otros parámetros a tener en cuenta serían KB_read y KB_wrtn, que podrían dar evidencias de un uso intensivo de disco.
MySQL
Si nos centramos en el propio MySQL, podríamos definir nuestra estrategia de revisión en dos niveles; un primer nivel global en el que llevaríamos a cabo una revisión de lo que se está ejecutando en la propia base de datos, y un segundo nivel en el que se analizaría lo que ocurre en el motor de la base de datos, que es la que se encarga de las operaciones de I/O, que es uno de los principales cuellos de botella.
En cuanto al primero de los niveles, nos interesaría obtener lo antes posible la volumetría de los siguientes puntos:
El número de consultas por segundo que el servidor de base de datos está gestionando
El número de usuarios que están conectados (conexiones activas)
La existencia de lo que denominamos slow queries en ejecución
Errores registrados en el log de MySQL
Los dos primeros puntos se puedes obtener con un simple SHOW PROCESSLIST y SHOW GLOBAL STATUS desde un cliente de MySQL. Ordenar los procesos por tiempo de ejecución, también suele ser bastante revelador permitiéndonos por ejemplo identificar procesos que están provocando bloqueos de tablas e impidiendo la ejecución de otros procesos.
También podemos utilizar herramientas como mytop, que nos proporciona información de un modo más amigable.
Si lo que queremos es analizar la existencia de slow queries, tendríamos que contar con la variable slow-query-log activada y un valor razonable para la variable long_query_time. En el fichero de log podríamos analizar el número y detalle de consultas que están superando el tiempo establecido
Por ultimo, es recomendable revisar el log de MySQL, de modo que podamos cerciorarnos de que no hay trazas de algún nuevo error que no hayamos visto anteriormente.
En cuanto al segundo nivel que mencionamos anteriormente, nos centraremos en las estadísticas del motor de base de datos. Esa información la podemos obtener de InnoDB a través del comando SHOW ENGINE INNODB STATUS.
La información que proporciona es muy extensa, y principalmente me voy a interesar en algunas estadísticas de más alto nivel.
Normalmente, uno de los parámetros que suelo revisar es Buffer pool hit rate. Lo ideal sería encontrar un valor lo más cercano a 1000. También son representativos los valores correspondientes a lecturas y escrituras por segundo; si alguno de estos valores es muy elevado, podría haber indicios de un alto número de operaciones de I/O, que ya hemos comentado anteriormente con la herramienta iostat.
En este artículo se ha presentado una guía de tareas esenciales y de primera acción que se pueden llevar a cabo para detectar problemas en entornos con bases de datos MySQL.
Evidentemente, existen otras muchas razones por las que se pueden presentar degradaciones de rendimiento, como por ejemplo un cambio de configuración hardware en la memoria o la CPU, modificaciones recientes en los parámetros de configuración (tunning), o incluso modificaciones llevadas a cabo en las aplicaciones que se conectan a la base de datos desde el punto de vista de desarrollo.
En todos los casos dotar a nuestra infraestructura de un correcto nivel de monitorización y alarmado con herramientas que hagan una revisión continuada y 24x7 de la operativa y rendimiento es un factor esencial. Este aspecto sumado a un correcto nivel de conocimiento a nivel administrativo de la base de datos y de los aplicaciones que interaccionan con ella es el camino para conseguir una estabilidad y un adecuado rendimiento.
