Tratar con consultas de ejecución prolongada de MySQL

Las consultas/declaraciones/transacciones de larga ejecución a veces son inevitables en un entorno MySQL. En algunas ocasiones, una consulta de larga duración podría ser el catalizador de un evento desastroso. Si le importa su base de datos, la optimización del rendimiento de las consultas y la detección de consultas de ejecución prolongada deben realizarse con regularidad. Sin embargo, las cosas se ponen más difíciles cuando se involucran varias instancias en un grupo o clúster.

Cuando se trata de múltiples nodos, las tareas repetitivas para verificar cada uno de los nodos son algo que debemos evitar. ClusterControl monitorea múltiples aspectos de su servidor de base de datos, incluidas las consultas. ClusterControl agrega toda la información relacionada con las consultas de todos los nodos del grupo o clúster para proporcionar una vista centralizada de la carga de trabajo. Justo ahí hay una excelente manera de comprender su clúster como un todo con un esfuerzo mínimo.

En esta publicación de blog, le mostramos cómo detectar consultas MySQL de ejecución prolongada mediante ClusterControl.

¿Por qué una consulta lleva más tiempo?

En primer lugar, debemos conocer la naturaleza de la consulta, si se espera que sea una consulta de ejecución prolongada o breve. Se supone que algunas operaciones analíticas y por lotes son consultas de ejecución prolongada, por lo que podemos omitirlas por ahora. Además, dependiendo del tamaño de la tabla, modificar la estructura de la tabla con el comando ALTER puede ser una operación de larga duración.

Para una transacción de corto plazo, debe ejecutarse lo más rápido posible, generalmente en una fracción de segundo. Cuanto más corto, mejor. Esto viene con un conjunto de reglas de mejores prácticas de consulta que los usuarios deben seguir, como usar la indexación adecuada en la declaración WHERE o JOIN, usar el motor de almacenamiento correcto, seleccionar los tipos de datos adecuados, programar la operación por lotes durante las horas de menor actividad, descargar análisis /informe de tráfico a réplicas dedicadas, etc.

Hay una serie de cosas que pueden hacer que una consulta tarde más tiempo en ejecutarse:

Consulta ineficiente:use columnas no indexadas al buscar o unirse, por lo que MySQL tarda más en cumplir la condición.
Bloqueo de tabla:la tabla está bloqueada mediante bloqueo global o bloqueo de tabla explícito cuando la consulta intenta acceder a ella.
Bloqueo:una consulta está esperando para acceder a las mismas filas que están bloqueadas por otra consulta.
El conjunto de datos no cabe en la RAM:si los datos de su conjunto de trabajo caben en ese caché, las consultas SELECT generalmente serán relativamente rápidas.
Recursos de hardware subóptimos:esto podría ser discos lentos, reconstrucción de RAID, red saturada, etc.
Operación de mantenimiento:la ejecución de mysqldump puede traer grandes cantidades de datos que de otro modo no se usarían al grupo de búfer y, al mismo tiempo, los datos (potencialmente útiles) que ya están allí serán desalojados y vaciados en el disco.

La lista anterior enfatiza que no es solo la consulta en sí misma la que causa todo tipo de problemas. Hay muchas razones que requieren mirar diferentes aspectos de un servidor MySQL. En el peor de los casos, una consulta de ejecución prolongada podría causar una interrupción total del servicio, como la caída del servidor, la caída del servidor y el agotamiento de las conexiones. Si ve que una consulta tarda más de lo habitual en ejecutarse, investíguela.

¿Cómo verificar?

LISTA DE PROCESOS

MySQL proporciona una serie de herramientas integradas para verificar la transacción de larga duración. En primer lugar, los comandos SHOW PROCESSLIST o SHOW FULL PROCESSLIST pueden exponer las consultas en ejecución en tiempo real. Esta es una captura de pantalla de la función Consultas en ejecución de ClusterControl, similar al comando MOSTRAR LISTA DE PROCESOS COMPLETA (pero ClusterControl agrega todo el proceso en una sola vista para todos los nodos del clúster):

Como puede ver, podemos ver inmediatamente la consulta ofensiva desde el resultado. Pero, ¿con qué frecuencia nos fijamos en esos procesos? Esto solo es útil si está al tanto de la transacción de larga duración. De lo contrario, no lo sabría hasta que suceda algo, como que las conexiones se acumulan o el servidor se vuelve más lento de lo normal.

Registro de consultas lentas

El registro de consultas lentas captura consultas lentas (instrucciones SQL que tardan más de long_query_time) segundos para ejecutarse), o consultas que no usan índices para búsquedas (log_queries_not_using_indexes ). Esta función no está habilitada de forma predeterminada y para habilitarla simplemente configure las siguientes líneas y reinicie el servidor MySQL:

[mysqld]
slow_query_log=1
long_query_time=0.1
log_queries_not_using_indexes=1

El registro de consultas lentas se puede utilizar para buscar consultas que tardan mucho tiempo en ejecutarse y, por lo tanto, son candidatas para la optimización. Sin embargo, examinar un registro de consultas largo y lento puede ser una tarea que requiere mucho tiempo. Existen herramientas para analizar los archivos de registro de consultas lentas de MySQL y resumir su contenido, como mysqldumpslow, pt-query-digest o ClusterControl Top Queries.

Las consultas principales de ClusterControl resumen la consulta lenta mediante dos métodos:el registro de consultas lentas de MySQL o el esquema de rendimiento:

Puede ver fácilmente un resumen de los resúmenes de declaraciones normalizados, ordenados según una serie de criterios:

Anfitrión
Ocurrencias
Tiempo total de ejecución
Tiempo máximo de ejecución
Tiempo medio de ejecución
Tiempo de desviación estándar

Hemos cubierto esta función con gran detalle en esta publicación de blog, Cómo usar el Monitor de consultas de ClusterControl para MySQL, MariaDB y Percona Server.

Esquema de rendimiento

Performance Schema es una gran herramienta disponible para monitorear las partes internas del servidor MySQL y los detalles de ejecución en un nivel inferior. Las siguientes tablas en Performance Schema se pueden usar para encontrar consultas lentas:

eventos_declaraciones_actuales
eventos_declaraciones_historial
events_statements_history_long
events_statements_summary_by_digest
events_statements_summary_by_user_by_event_name
events_statements_summary_by_host_by_event_name

MySQL 5.7.7 y versiones posteriores incluyen el esquema sys, un conjunto de objetos que ayuda a los administradores de bases de datos ya los desarrolladores a interpretar los datos recopilados por el esquema de rendimiento en una forma más comprensible. Los objetos de esquema del sistema se pueden usar para casos de uso típicos de ajuste y diagnóstico.

ClusterControl proporciona asesores, que son miniprogramas que puede escribir utilizando ClusterControl DSL (similar a JavaScript) para ampliar las capacidades de supervisión de ClusterControl según sus necesidades. Se incluyen varios scripts basados en el esquema de rendimiento que puede usar para monitorear el rendimiento de las consultas, como la espera de E/S, el tiempo de espera de bloqueo, etc. Por ejemplo, en Administrar -> Developer Studio , vaya a s9s -> mysql -> p_s -> top_tables_by_iowait.js y haga clic en el botón "Compilar y ejecutar". Debería ver el resultado en la pestaña Mensajes para las 10 tablas principales ordenadas por espera de E/S por servidor:

Hay una serie de secuencias de comandos que puede usar para comprender la información de bajo nivel dónde y por qué ocurre la lentitud como top_tables_by_lockwait.js , top_accessed_db_files.js y así sucesivamente.

ClusterControl:detección y alertas sobre consultas de ejecución prolongada

Con ClusterControl, obtendrá potentes funciones adicionales que no encontrará en la instalación estándar de MySQL. ClusterControl se puede configurar para monitorear de manera proactiva los procesos en ejecución y generar una alarma y enviar una notificación al usuario si se excede el umbral de consulta larga. Esto se puede configurar usando la Configuración de tiempo de ejecución en Configuración:

Para versiones anteriores a 1.7.1, el valor predeterminado para query_monitor_alert_long_running_query Es falso. Alentamos al usuario a habilitar esto estableciéndolo en 1 (verdadero). Para hacerlo persistente, agregue la siguiente línea en /etc/cmon.d/cmon_X.cnf:

query_monitor_alert_long_running_query=1
query_monitor_long_running_query_ms=30000

Cualquier cambio realizado en la configuración de tiempo de ejecución se aplica inmediatamente y no es necesario reiniciar. Verá algo como esto en la sección Alarmas si una consulta supera los umbrales de 30 000 ms (30 segundos):

Si configura los ajustes del destinatario de correo como "Entregar" para la categoría de gravedad DbComponent más CRÍTICA (como se muestra en la siguiente captura de pantalla):

Debería recibir una copia de esta alarma en su correo electrónico. De lo contrario, se puede reenviar manualmente haciendo clic en el botón "Enviar correo electrónico".

Además, puede filtrar cualquier tipo de recurso de lista de procesos que coincida con ciertos criterios con expresiones regulares (regex). Por ejemplo, si desea que ClusterControl detecte una consulta de ejecución prolongada para tres usuarios de MySQL llamados 'sbtest', 'myshop' y 'db_user1', debería hacer lo siguiente:

Cualquier cambio realizado en la configuración de tiempo de ejecución se aplica inmediatamente y no es necesario reiniciar.

Además, ClusterControl enumerará todas las transacciones de interbloqueo junto con el estado de InnoDB cuando ocurría en Rendimiento -> Registro de transacciones :

Esta función no está habilitada de forma predeterminada, debido a que la detección de puntos muertos afectará el uso de la CPU en los nodos de la base de datos. Para habilitarlo, simplemente marque la casilla de verificación "Habilitar registro de transacciones" y especifique el intervalo que desea. Para hacerlo persistente, agregue una variable con valor en segundos dentro de /etc/cmon.d/cmon_X.cnf:

db_deadlock_check_interval=30

Del mismo modo, si desea verificar el estado de InnoDB, simplemente vaya a Rendimiento -> Estado de InnoDB y elija el servidor MySQL del menú desplegable. Por ejemplo:

Allá vamos:toda la información necesaria se puede recuperar fácilmente con un par de clics.

Resumen

Las transacciones de ejecución prolongada podrían provocar una degradación del rendimiento, caída del servidor, conexiones al máximo y puntos muertos. Con ClusterControl, puede detectar consultas de ejecución prolongada directamente desde la interfaz de usuario, sin necesidad de examinar cada uno de los nodos de MySQL en el clúster.