sql >> Base de Datos >  >> RDS >> Mysql

Sugerencias para lograr el rendimiento de la base de datos MySQL:segunda parte

La gestión del rendimiento de la base de datos es un área en la que los administradores suelen dedicar más tiempo del esperado a las empresas.

Supervisar y reaccionar ante los problemas de rendimiento de la base de datos de producción es una de las tareas más críticas dentro de un trabajo de administrador de base de datos. Es un proceso continuo que requiere un cuidado constante. La aplicación y las bases de datos subyacentes suelen evolucionar con el tiempo; crecer en tamaño, número de usuarios, carga de trabajo, cambios de esquema que vienen con cambios de código.

Las consultas de ejecución prolongada rara vez son inevitables en una base de datos MySQL. En algunas circunstancias, una consulta de ejecución prolongada puede ser un evento dañino. 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.

En este blog, analizaremos más en profundidad la carga de trabajo real de la base de datos, especialmente en el lado de las consultas en ejecución. Comprobaremos cómo realizar un seguimiento de las consultas, qué tipo de información podemos encontrar en los metadatos de MySQL, qué herramientas usar para analizar dichas consultas.

Manejo de consultas de larga duración

Empecemos comprobando las consultas de ejecución prolongada. 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 (especialmente en MySQL Galera Clusters).

  • Bloqueo de tabla:la tabla está bloqueada por un bloqueo global o un bloqueo de tabla explícito cuando la consulta intenta acceder a ella.
  • Consulta ineficiente:utilice columnas no indexadas al buscar o unirse, por lo que MySQL tarda más en cumplir la condición.
  • Bloqueo:una consulta está esperando para acceder a las mismas filas que están bloqueadas por otra solicitud.
  • 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.

Si ve que una consulta tarda más de lo normal en ejecutarse, investíguela.

Uso de la lista de procesos de visualización de MySQL

​MYSQL> SHOW PROCESSLIST;

Esto suele ser lo primero que ejecuta en caso de problemas de rendimiento. SHOW PROCESSLIST es un comando mysql interno que le muestra qué subprocesos se están ejecutando. También puede ver esta información desde la tabla information_schema.PROCESSLIST o el comando mysqladmin process list. Si tiene el privilegio PROCESS, puede ver todos los subprocesos. Puede ver información como el Id. de consulta, el tiempo de ejecución, quién la ejecuta, el host del cliente, etc. La información es un poco cautelosa según el tipo y la distribución de MySQL (Oracle, MariaDB, Percona)

SHOW PROCESSLIST;

+----+-----------------+-----------+------+---------+------+------------------------+------------------+----------+

| Id | User            | Host | db | Command | Time | State                  | Info | Progress |

+----+-----------------+-----------+------+---------+------+------------------------+------------------+----------+

|  2 | event_scheduler | localhost | NULL | Daemon  | 2693 | Waiting on empty queue | NULL   | 0.000 |

|  4 | root            | localhost | NULL | Query   | 0 | Table lock   | SHOW PROCESSLIST | 0.000 |

+----+-----------------+-----------+------+---------+------+------------------------+------------------+----------+

podemos ver inmediatamente la consulta ofensiva desde el resultado. En el ejemplo anterior, podría ser un bloqueo de tabla. Pero, ¿con qué frecuencia nos fijamos en esos procesos? Esto solo es útil si conoce 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.

Uso de MySQL Pt-query-digest

Si desea ver más información sobre una carga de trabajo en particular, use pt-query-digest. El pt-query-digest es una herramienta de Linux de Percona para analizar consultas de MySQL. Es parte del kit de herramientas de Percona que puedes encontrar aquí. Es compatible con las distribuciones de Linux de 64 bits más populares, como Debian, Ubuntu y Redhat.

Para instalarlo debes configurar los repositorios de Percona y luego instalar el paquete perona-toolkit.

Instala Percona Toolkit usando tu administrador de paquetes:

Debian o Ubuntu:

sudo apt-get install percona-toolkit

RHEL o CentOS:

sudo yum install percona-toolkit

Pt-query-digest acepta datos de la lista de procesos, registro general, registro binario, registro lento o tcpdump Además de eso, es posible sondear la lista de procesos de MySQL en un intervalo definido:un proceso eso puede requerir muchos recursos y estar lejos de ser ideal, pero aún puede usarse como una alternativa.

La fuente más común de pt-query-digest es un registro de consultas lentas. Puede controlar la cantidad de datos que irán allí con el parámetro log_slow_verbosity.

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

  • microtime - consultas con precisión de microsegundos.
  • query_plan:información sobre el plan de ejecución de la consulta.
  • innodb :estadísticas de InnoDB.
  • mínimo:equivalente a habilitar solo el microtiempo.
  • estándar:equivalente a habilitar microtime,innodb.
  • completo:equivalente a todos los demás valores combinados con OR sin las opciones de perfilado y perfilado_uso_getrusage.
  • perfilado:activa el perfilado de todas las consultas en todas las conexiones.
  • profiling_use_getrusage - Habilita el uso de la función getrusage.

fuente:documentación de Percona

Para completar, use log_slow_verbosity=full, que es un caso común.

Registro de consultas lentas

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. El registro de consultas lentas captura consultas lentas (instrucciones SQL que tardan más de long_query_time segundos en 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
log_queries_not_using_indexes=1
long_query_time=0.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.

Esquema de rendimiento

Performance Schema es una excelente herramienta disponible para monitorear los detalles internos y de ejecución de MySQL Server en un nivel inferior. Tenía mala reputación en una versión anterior (5.6) porque habilitarlo a menudo causaba problemas de rendimiento; sin embargo, las versiones recientes no dañan el rendimiento. Las siguientes tablas en Performance Schema se pueden usar para encontrar consultas lentas:

  • eventos_declaraciones_actuales
  • eventos_declaraciones_historial
  • eventos_declaraciones_historial_largo
  • 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.

Seguimiento de red

¿Qué sucede si no tenemos acceso al registro de consultas o registros directos de la aplicación? En ese caso, podríamos usar una combinación de tcpdump y pt-query digest que podría ayudar a capturar consultas.

$ tcpdump -s 65535 -x -nn -q -tttt -i any port 3306 > mysql.tcp.txt

Una vez finalizado el proceso de captura, podemos proceder con el procesamiento de los datos:

$ pt-query-digest --limit=100% --type tcpdump mysql.tcp.txt > ptqd_tcp.out

Monitor de consultas de ClusterControl

ClusterControl Query Monitor es un módulo en un control de clúster que proporciona información combinada sobre la actividad de la base de datos. Puede recopilar información de múltiples fuentes, como mostrar la lista de procesos o el registro de consultas lentas, y presentarla de forma agregada previamente.

La supervisión de SQL se divide en tres secciones.

Consultas principales

presenta la información sobre las consultas que consumen una parte significativa de los recursos.

Ejecución de consultas

es una lista de procesos de información combinada de todos los nodos del clúster de la base de datos en una sola vista. Puede usarlo para eliminar las consultas que afectan las operaciones de su base de datos.

Consultar valores atípicos

presenta la lista de consultas con un tiempo de ejecución superior al promedio.

Conclusión

Esto es todo por la segunda parte. Este blog no pretende ser una guía exhaustiva sobre cómo mejorar el rendimiento de la base de datos, pero se espera que brinde una imagen más clara de qué cosas pueden volverse esenciales y algunos de los parámetros básicos que se pueden configurar. No dude en informarnos si nos hemos perdido alguno importante en los comentarios a continuación.