El mal rendimiento de las consultas es el problema más común con el que tienen que lidiar los administradores de bases de datos. Existen numerosas formas de recopilar, procesar y analizar los datos relacionados con el rendimiento de las consultas:hemos cubierto una de las herramientas más populares, pt-query-digest, en algunas de nuestras publicaciones de blog anteriores:
Conviértase en una serie de blogs MySQL DBA
- Análisis de su carga de trabajo de SQL mediante pt-query-digest
- Análisis detallado de la carga de trabajo de SQL mediante pt-query-digest
Sin embargo, cuando usa ClusterControl, esto no siempre es necesario. Puede utilizar los datos disponibles en ClusterControl para resolver su problema. En esta publicación de blog, veremos cómo ClusterControl puede ayudarlo a resolver problemas relacionados con el rendimiento de las consultas.
Puede suceder que una consulta no pueda completarse a tiempo. La consulta puede estar atascada debido a algunos problemas de bloqueo, puede no ser óptima o no estar indexada correctamente o puede ser demasiado pesada para completarla en un tiempo razonable. Tenga en cuenta que un par de uniones no indexadas pueden escanear fácilmente miles de millones de filas si tiene una gran base de datos de producción. Pase lo que pase, la consulta probablemente esté utilizando algunos de los recursos, ya sea CPU o E/S para una consulta no optimizada o incluso solo bloqueos de fila. Esos recursos también se requieren para otras consultas y pueden ralentizar seriamente las cosas. Una de las tareas más simples pero importantes sería identificar la consulta infractora y detenerla.
Es bastante fácil de hacer desde la interfaz de ClusterControl. Vaya a la pestaña Monitor de consultas -> sección Consultas en ejecución; debería ver un resultado similar a la captura de pantalla a continuación.
Como puede ver, tenemos un montón de consultas atascadas. Por lo general, la consulta ofensiva es la que lleva mucho tiempo, es posible que desee eliminarla. También es posible que desee investigarlo más a fondo para asegurarse de elegir el correcto. En nuestro caso, vemos claramente SELECCIONAR... PARA ACTUALIZAR que une un par de tablas y que está en el estado "Enviando datos", lo que significa que está procesando los datos, durante los últimos 90 segundos.
Otro tipo de pregunta que un DBA puede necesitar responder es:¿qué consultas tardan más en ejecutarse? Esta es una pregunta común, ya que tales consultas pueden ser una fruta al alcance de la mano:pueden optimizarse, y cuanto más tiempo de ejecución sea responsable de una consulta determinada en una combinación de consultas completa, mayor será la ganancia de su optimización. Es una ecuación simple:si una consulta es responsable del 50 % del tiempo de ejecución total, hacerla 10 veces más rápida dará un resultado mucho mejor que optimizar una consulta que es responsable de solo el 1 % del tiempo de ejecución total.
ClusterControl puede ayudarlo a responder tales preguntas, pero primero debemos asegurarnos de que Query Monitor esté habilitado. Puede activar el Monitor de consultas en la página Monitor de consultas. Además, puede configurar las opciones "Tiempo de consulta prolongado" y "Registrar consultas que no usan índices" en Configuración para adaptarse a su carga de trabajo:
Query Monitor en ClusterControl funciona en dos modos, dependiendo de si tiene el esquema de rendimiento disponible con los datos requeridos en las consultas en ejecución o no. Si está disponible (y esto es así de forma predeterminada en MySQL 5.6 y posteriores), se usará Performance Schema para recopilar datos de consulta, minimizando el impacto en el sistema. De lo contrario, se usará el registro de consultas lentas y se usarán todas las configuraciones visibles en la captura de pantalla anterior. Están bastante bien explicados en la interfaz de usuario, por lo que no es necesario hacerlo aquí. Cuando Query Monitor usa el esquema de rendimiento, esa configuración no se usa (excepto para activar o desactivar Query Monitor para habilitar o deshabilitar la recopilación de datos).
Cuando confirme que Query Monitor está habilitado en ClusterControl, puede ir a Query Monitor -> Consultas principales, donde se le presentará una pantalla similar a la siguiente:
Lo que puede ver aquí es una lista de las consultas más costosas (en términos de tiempo de ejecución) que llegan a nuestro clúster. Cada uno de ellos tiene algunos detalles adicionales:cuántas veces se ejecutó, cuántas filas se examinaron o enviaron al cliente, cómo varió el tiempo de ejecución, cuánto tiempo dedicó el clúster a ejecutar un determinado tipo de consulta. Las consultas se agrupan por tipo de consulta y esquema.
Es posible que se sorprenda al descubrir que el lugar principal donde se gasta el tiempo de ejecución es una consulta 'COMMIT'. En realidad, esto es bastante típico para consultas OLTP rápidas ejecutadas en el clúster de Galera. Confirmar una transacción es un proceso costoso porque la certificación tiene que ocurrir. Esto lleva a que COMMIT sea una de las consultas que consume más tiempo en la combinación de consultas.
Cuando hace clic en una consulta, puede ver la consulta completa, el tiempo máximo de ejecución, la cantidad de ocurrencias, algunos consejos generales de optimización y un resultado EXPLICAR para ella, bastante útil para identificar si hay algún problema. En nuestro ejemplo, hemos marcado SELECCIONAR... PARA ACTUALIZAR con una gran cantidad de filas examinadas. Como era de esperar, esta consulta es un ejemplo de SQL terrible:un JOIN que no usa ningún índice. Puede ver en la salida de EXPLAIN que no se usa ningún índice, ni uno solo se consideró posible de usar. No es de extrañar que esta consulta haya afectado gravemente el rendimiento de nuestro clúster.
Otra forma de obtener una idea del rendimiento de las consultas es consultar Monitor de consultas -> Valores atípicos de consultas. Esta es básicamente una lista de consultas cuyo rendimiento difiere significativamente de su promedio.
Como puede ver en la captura de pantalla anterior, la segunda consulta tomó 0,01116 s (el tiempo se muestra en milisegundos), donde el tiempo de ejecución promedio para esa consulta es mucho menor (0,000142 s). También tenemos información estadística adicional sobre la desviación estándar y el tiempo máximo de ejecución de consultas. Tal lista de consultas puede parecer poco útil, en realidad no es cierto. Cuando vea una consulta en esta lista, significa que algo fue diferente de lo habitual:la consulta no se completó en el tiempo normal. Puede ser una indicación de algunos problemas de rendimiento en su sistema y una señal de que debe investigar otras métricas y verificar si sucedió algo más en ese momento.
La gente tiende a centrarse en lograr el máximo rendimiento, olvidando que no es suficiente tener un alto rendimiento, también tiene que ser consistente. A los usuarios les gusta que el rendimiento sea estable:es posible que pueda exprimir más transacciones por segundo de su sistema, pero si eso significa que algunas transacciones comenzarán a detenerse por segundos, no vale la pena. Mirar el histograma de consultas en ClusterControl lo ayuda a identificar tales problemas de coherencia en su combinación de consultas.
¡Feliz seguimiento de consultas!
PD:¡Para comenzar con ClusterControl, haga clic aquí!
