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

Monitoreo efectivo de MySQL con SCUMM Dashboards:Parte 3

Hablamos en nuestros blogs anteriores sobre los paneles relacionados con MySQL. Destacamos las cosas de las que un DBA puede beneficiarse al estudiar los gráficos, especialmente cuando realiza sus rutinas diarias de diagnóstico, informes de métricas y planificación de capacidad. En este blog, analizaremos las métricas de InnoDB y el esquema de rendimiento de MySQL, que es muy importante, especialmente para monitorear transacciones de InnoDB, E/S de disco/cpu/memoria, optimizar sus consultas o ajustar el rendimiento del servidor.

Este blog toca el tema profundo del rendimiento, considerando que InnoDB requeriría una amplia cobertura si abordamos sus aspectos internos. El esquema de rendimiento también es extenso, ya que cubre el kernel y las partes centrales de MySQL y los motores de almacenamiento.

Empecemos a recorrer los gráficos.

Métricas MySQL InnoDB

Este tablero es excelente para cualquier administrador de bases de datos de MySQL o persona de operaciones, ya que ofrece una muy buena vista del motor de almacenamiento InnoDB. Hay ciertos gráficos aquí que un usuario debe considerar para habilitarlos, porque no en todas las situaciones las variables están configuradas correctamente en la configuración de MySQL.

  • Edad del punto de control de Innodb

    Según el manual, los puntos de control se definen de la siguiente manera:“A medida que se realizan cambios en las páginas de datos que se almacenan en caché en el grupo de búfer , esos cambios se escriben en los archivos de datos algún tiempo después, un proceso conocido como lavado . El punto de control es un registro de los últimos cambios (representado por un LSN valor) que se han escrito con éxito en los archivos de datos ”. Este gráfico es útil cuando desea determinar cómo su servidor realiza el control de datos en su disco. Esta puede ser una buena referencia si su registro de transacciones (redo log o ib_logfile0) es demasiado grande. Este gráfico también es un buen indicador si necesita ajustar variables como innodb_log_file_size, innodb_log_buffer_size, innodb_max_dirty_pages_pct o innodb_adaptive_flushing_method. Cuanto más cerca esté la edad del punto de control de la edad máxima del punto de control, más llenos estarán los registros e InnoDB realizará más E/S para mantener algo de espacio libre en los registros. El mecanismo de puntos de control difiere en detalles sutiles entre los sabores basados ​​en Percona XtraDB, MariaDB y la versión de Oracle, también puede encontrar diferencias en su implementación entre las versiones de MySQL.

  • Transacciones InnoDB

    Siempre que haya una gran transacción en curso en su servidor MySQL, este gráfico es una buena referencia. Contará las transacciones que se crearon en un momento específico, y la longitud del historial (o es en realidad la longitud de la lista del historial que se encuentra en SHOW ENGINE INNODB STATUS) es el número de páginas en el registro de deshacer. Las tendencias que verá aquí son un buen recurso para verificar si podría significar, por ejemplo, que la purga se retrasa debido a una tasa de inserción muy alta de recarga de datos o debido a una transacción de ejecución prolongada, o si la purga simplemente puede no se mantiene al día debido a una alta E/S de disco en el volumen donde reside su $DATADIR.

  • Operaciones de fila de Innodb

    Para ciertas tareas de DBA, es posible que desee determinar la cantidad de eliminaciones, inserciones, lecturas y filas actualizadas. Entonces este gráfico es lo que puede usar para comprobarlos.

  • Tiempo de bloqueo de fila Innodb

    Este gráfico es un buen recurso para mirar cuando se da cuenta de que su aplicación está encontrando muchas ocurrencias de “Se excedió el tiempo de espera de bloqueo; intente reiniciar la transacción ”. Esto también puede ayudarlo a determinar si puede tener una indicación para usar consultas incorrectas en el manejo de bloqueos. Esta también es una buena referencia para tener en cuenta al optimizar sus consultas que implican el bloqueo de filas. Si el tiempo de espera es demasiado alto, debe verificar el registro de consultas lentas o ejecutar un pt-query-digest y ver cuáles son esas consultas sospechosas que causan esa hinchazón en el gráfico.

  • E/S de InnoDB

    Cada vez que desee determinar la cantidad de lecturas de datos InnoDB, vaciados de disco, escrituras y escrituras de registro, este gráfico tiene lo que necesita mirar. Puede usar este gráfico para determinar si sus variables InnoDB están bien ajustadas para manejar sus requisitos específicos. Por ejemplo, si tiene caché del módulo de respaldo de batería pero no está obteniendo mucho de su rendimiento óptimo, puede confiar en este gráfico para determinar si sus fsyncs() son más altos de lo esperado. Luego, cambiar la variable innodb_flush_method y usar O_DSYNC puede resolver el problema.

  • Uso del archivo de registro de InnoDB por hora

    Este gráfico muestra solo la cantidad de bytes escritos en los archivos de registro de rehacer de InnoDB y el crecimiento de sus archivos de registro de InnoDB según el intervalo de tiempo de 24 horas de la fecha actual.

  • Rendimiento de registro de InnoDB

    Este gráfico está estrechamente relacionado con el gráfico de uso por hora del archivo de registro de InnoDB. Debe usar este gráfico cada vez que necesite determinar qué tan grande debe ser su innodb_log_file_size. Puede determinar la cantidad de bytes escritos en los archivos de registro de rehacer de InnoDB y la eficiencia con la que MySQL vacía los datos de la memoria al disco. Siempre que tenga poco tiempo y necesite usar su espacio de registro de rehacer, indicaría que tiene que aumentar el tamaño de su innodb_log_file. En ese caso, este gráfico le diría que debe hacerlo. Sin embargo, para profundizar más en cuánto necesita para su innodb_log_file, podría tener más sentido verificar el LSN (Número de secuencia de registro) en SHOW ENGINE INNODB STATUS. Percona tiene un buen blog relacionado con esto, que es una buena fuente para consultar.

  • Interbloqueos de InnoDB

    En ciertas situaciones en las que el cliente de su aplicación a menudo experimenta interbloqueos o tiene que ver cuántos interbloqueos experimenta MySQL, este gráfico sirve para este propósito. Los interbloqueos indican que tiene un diseño de SQL deficiente, lo que hace que sus transacciones creen una condición de carrera que provoca interbloqueos.

  • Desplazamiento de la condición del índice

    Una pequeña advertencia al mirar este gráfico. Primero, debe determinar que tiene su variable global MySQL innodb_monitor_enable establecida en el valor correcto que es module_icp. De lo contrario, experimentará un "Sin puntos de datos" como se muestra a continuación:

    El propósito del gráfico, si tiene puntos de datos definidos como lo que tengo en los resultados de muestra, proporcionará a un DBA una visión general de qué tan bien se benefician sus consultas con Index Condition Pushdown o ICP para abreviar. ICP es una gran característica en MySQL que ofrece optimización para sus consultas. En lugar de que MySQL lea las filas completas filtradas en sus consultas WHERE al recuperarlas, agregará más comprobaciones después de sus índices secundarios. Esto agrega más granularidad y ahorra tiempo; de lo contrario, el motor tiene que leer las filas de la tabla completa cuando se basa solo en el índice filtrado y no se usa ICP. Esto evita leer las filas completas correspondientes a sus tuplas de índice que coinciden con sus índices secundarios.

    Permítanme elaborar un poco sobre este gráfico, digamos que tengo una tabla llamada:

    mysql> show create table a\G
*************************** 1. row ***************************
       Table: a
Create Table: CREATE TABLE `a` (
  `id` int(11) NOT NULL,
  `age` int(11) NOT NULL,
  KEY `id` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

    Y tiene algunos pequeños datos:

    mysql> select * from a;
+----+-----+
| id | age |
+----+-----+
|  1 |   1 |
|  2 |   1 |
|  3 |   1 |
|  3 |  41 |
|  4 |  41 |
|  5 |   4 |
|  4 |   4 |
|  4 |   4 |
+----+-----+
8 rows in set (0.00 sec)

    Cuando ICP está habilitado, los resultados son más eficientes y factibles:

    mysql> explain extended select * from a where id>2 and id<4 and age=41;
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
| id | select_type | table | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra                              |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
|  1 | SIMPLE      | a     | NULL       | range | id            | id   | 4       | NULL |    2 |    12.50 | Using index condition; Using where |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
1 row in set, 2 warnings (0.00 sec)

    Que sin PIC,

    mysql> set optimizer_switch='index_condition_pushdown=off';
Query OK, 0 rows affected (0.00 sec)

mysql> explain extended select * from a where id>2 and id<4 and age=41;
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | a     | NULL       | range | id            | id   | 4       | NULL |    2 |    12.50 | Using where |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
1 row in set, 2 warnings (0.00 sec)

    Este es un ejemplo simple de ICP y cómo este gráfico puede beneficiar a un DBA.

  • Contenido del grupo de búfer de InnoDB

    Cuando se trabaja con MySQL y se usa el motor InnoDB, este gráfico es uno de los valores más comunes (innodb_buffer_pool*) que debe ajustar para optimizar el rendimiento de MySQL. Hablando específicamente sobre el contenido de su grupo de búfer, muestra las tendencias de páginas sucias contra el contenido total del grupo de búfer. El contenido total del grupo de búfer incluye las páginas limpias además de las páginas sucias. Este gráfico sirve para determinar qué tan eficientemente su MySQL está manejando el grupo de búfer.

  • Páginas de grupos de búfer de InnoDB

    Este gráfico es útil cuando desea verificar qué tan eficiente es MySQL usando su grupo de búfer InnoDB. Puede usar este gráfico, por ejemplo, si su tráfico diario no llena el innodb_buffer_pool_size asignado, entonces esto podría indicar que ciertas partes de una aplicación no son útiles o no tienen ningún propósito o si configura el innodb_buffer_pool_size muy alto lo que podría ser bueno para reducir el valor y recuperar espacio en la memoria.

  • E/S de grupo de búfer de InnoDB

    Cuando tenga que comprobar el número de páginas creadas y escritas en las tablas de InnoDB o las lecturas de páginas en el grupo de búfer de InnoDB mediante operaciones en las tablas de InnoDB.

  • Solicitudes de grupos de búfer de InnoDB

    Cuando desee determinar la eficiencia con la que sus consultas acceden al grupo de búfer de InnoDB, este gráfico sirve para este propósito. Este gráfico mostrará las tendencias basadas en los puntos de datos sobre cómo funciona su servidor MySQL cuando el motor InnoDB tiene que acceder con frecuencia al disco (la indicación del grupo de búfer aún no se ha calentado), con qué frecuencia las solicitudes del grupo de búfer manejaban las solicitudes de lectura y escritura. solicitudes.

  • Lectura anticipada de InnoDB

    Cuando tenga la variable innodb_random_read_ahead configurada en ON, agregue este gráfico como una tendencia valiosa para observar como parte de su rutina de DBA. Muestra las tendencias sobre cómo su motor de almacenamiento MySQL InnoDB administra el grupo de búfer por el subproceso de fondo de lectura anticipada, cómo administra los desalojados posteriormente sin haber sido accedidos por consultas, y cómo InnoDB inicia la lectura anticipada aleatoria cuando se escanea una consulta. una gran parte de una tabla pero en orden aleatorio.

  • Búfer de cambio de InnoDB

    Cuando se ejecuta Percona Server 5.7, este gráfico es útil para monitorear qué tan bien InnoDB ha asignado el búfer de cambios. Estos cambios incluyen las inserciones, actualizaciones y eliminaciones que especifica la variable innodb_change_buffering. El almacenamiento en búfer de cambios ayuda a acelerar las consultas, lo que evita la E/S de acceso aleatorio sustancial que sería necesaria para leer páginas de índice secundarias desde el disco.

  • Actividad de cambio de búfer de InnoDB

    Esto está relacionado con el gráfico de búfer de cambio de InnoDB, pero disecciona la información en puntos de datos más viables. Estos proporcionan más información para monitorear cómo InnoDB maneja el almacenamiento en búfer de cambios. Esto es útil en una tarea de DBA particular para determinar si su innodb_change_buffer_max_size está configurado en un valor demasiado alto, ya que el almacenamiento en búfer de cambio comparte la misma memoria del grupo de búfer de InnoDB, lo que reduce la memoria disponible para las páginas de datos en caché. Es posible que deba considerar deshabilitar el almacenamiento en búfer de cambios si el conjunto de trabajo casi cabe en el grupo de búfer, o si sus tablas tienen relativamente pocos índices secundarios. Recuerde que el almacenamiento en búfer de cambios no impone una sobrecarga adicional, ya que solo se aplica a las páginas que no están en el grupo de búfer. Este gráfico también es útil si tiene que determinar cómo las fusiones son útiles si tiene que comparar su aplicación en función de ciertas solicitudes para escenarios particulares. Digamos que tiene inserciones masivas, debe establecer innodb_change_buffering=insert y determinar si tener los valores establecidos en su grupo de búfer e innodb_change_buffer_max_size no afecta la E/S del disco, especialmente durante la recuperación o el apagado lento (necesario si desea hacer una conmutación por error con requisito de tiempo de inactividad bajo). Además, este gráfico puede servir para evaluar ciertos escenarios, ya que la fusión del búfer de cambios puede demorar varias horas cuando hay numerosos índices secundarios para actualizar y muchas filas afectadas. Durante este tiempo, la E/S del disco aumenta, lo que puede provocar una ralentización significativa de las consultas vinculadas al disco.

Esquema de rendimiento de MySQL

El esquema de rendimiento de MySQL es un tema complicado. Es largo y difícil, pero voy a discutir solo la información que es específica de los gráficos que tenemos en SCUMM. También hay ciertas variables que debe considerar y asegurarse de que estén configuradas correctamente. Asegúrese de tener su variable innodb_monitor_enable =all y userstat=1 para ver puntos de datos en sus gráficos. Como nota, cuando estoy usando la palabra "evento" aquí, no significa que esté relacionado con MySQL Event Scheduler. Estoy hablando de eventos específicos como MySQL analiza una consulta, MySQL está leyendo o escribiendo en un archivo de registro de retransmisión/binario, etc.

Procedamos entonces con los gráficos.

  • E/S de archivo de esquema de rendimiento (eventos)

    Este gráfico obtiene puntos de datos relacionados con los eventos que ocurrieron en MySQL que podrían haber sido instrumentados para crear múltiples instancias del objeto instrumentado (por ejemplo, lecturas de registros binarios o lecturas de archivos de datos InnoDB). Cada fila resume eventos para un nombre de evento dado. Por ejemplo, si hay un instrumento para un mutex que se crea para cada conexión, podría haber muchas instancias de este evento instrumentado ya que hay varias conexiones. La fila de resumen del instrumento resume todas estas instancias. Puede consultar estos eventos en el manual de MySQL para las tablas de resumen del esquema de rendimiento para obtener más información.

  • Archivo de esquema de rendimiento IO (Cargar)

    Este gráfico es el mismo que el gráfico "Performance Schema File IO (Events)", excepto que está instrumentado en función de la carga.

  • E/S de archivo de esquema de rendimiento (bytes)

    Este gráfico es el mismo que el gráfico "Performance Schema File IO (Events)", excepto que está instrumentado en función del tamaño en bytes. Por ejemplo, cuánto tiempo tomó un evento específico cuando MySQL activó el evento wait/io/file/innodb/innodb_data_file.

  • Esperas de esquema de rendimiento (eventos)

    Este gráfico tiene el gráfico de datos para todas las esperas pasadas en un evento específico. Puede consultar las tablas de resumen de eventos de espera en el manual para obtener más información.

  • Esperas de esquema de rendimiento (carga)

    Igual que el gráfico "Esquema de rendimiento en espera (eventos)", pero esta vez muestra las tendencias de la carga.

  • Operaciones de acceso a índices (carga)

    Este gráfico es una agregación de todos los eventos de espera de E/S de índice de tabla agrupados por índice(s) de una tabla, generados por el instrumento wait/io/table/sql/handler. Puede consultar el manual de MySQL sobre la tabla del esquema de rendimiento table_io_waits_summary_by_index_usage para obtener más información.

  • Operaciones de acceso a tablas (carga)

    El gráfico "Igual que Index Access Operations (Load)", es una agregación de todos los eventos de espera de E/S de tabla agrupados por tabla, generados por el instrumento wait/io/table/sql/handler. Esto es muy útil para los administradores de bases de datos. Por ejemplo, le gustaría rastrear qué tan rápido se tarda en acceder (obtener) o actualizar (insertar, eliminar, actualizar) una tabla específica. Puede consultar el manual de MySQL sobre la tabla del esquema de rendimiento table_io_waits_summary_by_table para obtener más información.

  • Esquema de rendimiento SQL y bloqueos externos (eventos)

    Este gráfico es una agregación (cuenta de cuántas veces ocurrió) de todos los eventos de espera de bloqueo de tabla, generados por el instrumento wait/lock/table/sql/handler que se agrupa por tabla. El bloqueo SQL aquí en el gráfico significa los bloqueos internos. Estos bloqueos internos son de lectura normal, lectura con bloqueos compartidos, lectura de alta prioridad, lectura sin inserción, escritura con permiso de escritura, escritura con inserción simultánea, escritura retrasada, escritura con baja prioridad y escritura normal. Mientras que los bloqueos externos son de lectura externa y escritura externa. En cualquier tarea de DBA, esto es muy útil si tiene que rastrear e investigar bloqueos en una tabla en particular, independientemente de su tipo. Puede consultar la tabla table_lock_waits_summary_by_table para obtener más información.

  • Esquema de rendimiento SQL y bloqueos externos (segundos)

    Igual que el gráfico "Performance Schema SQL &External Locks (Events)", pero especificado en segundos. Si desea buscar los bloqueos de su tabla en función de los segundos que mantuvo los bloqueos, entonces este gráfico es su buen recurso.

Conclusión

Las métricas de InnoDB y el esquema de rendimiento de MySQL son algunas de las partes más profundas y complicadas del dominio de MySQL, especialmente cuando no hay visualización para ayudar en la interpretación. Por lo tanto, ir a un rastreo manual e investigaciones puede tomar algo de su tiempo y trabajo duro. Los tableros de SCUMM ofrecen una forma muy eficiente y factible de manejar estos y reducir la carga adicional en cualquier tarea de rutina de DBA.

En este blog, aprendió a usar los paneles para InnoDB y Performance Schema para mejorar el rendimiento de la base de datos. Estos paneles pueden aumentar su eficiencia al analizar el rendimiento.