PERFORMANCE_SCHEMA frente a registro de consultas lentas

Hace un par de semanas, poco después de que Vadim escribiera Herramientas en la nube de Percona y usando Slow Query Log para capturar los datos, Mark Leith se preguntó por qué no deberíamos usar Performance Scheme en su lugar. Esta es una pregunta interesante y creo que merece su propia publicación de blog para hablar de ella.

Primero, diré la razón principal usar Slow Query Log es compatible. El registro básico de consultas lentas con un tiempo de consulta preciso en microsegundos está disponible en MySQL 5.1, mientras que events_statements_summary_by_digest La tabla solo se agregó en MySQL 5.6, que estuvo disponible durante aproximadamente un año, pero que aún está lejos de dominar por completo el mercado. Es especialmente interesante si observa el mercado de gama baja: usuarios que solo ejecutan ciertas aplicaciones web que usan cualquier versión de MySQL que su proveedor de alojamiento haya instalado para ellos. Si miras Usuarios de WordPress por ejemplo, ve MySQL 5.6 en solo 1.3% a partir de hoy. A medida que pasa el tiempo y MySQL 5.6 toma una mayor participación en el mercado, definitivamente deberíamos agregar soporte para el muestreo de consultas basado en esquemas de rendimiento para Herramientas en la nube de Percona.

La segunda razón es la cantidad de datos disponibles. Hay una buena cantidad de datos que Performance Schema digiere proveedores de tablas, incluidos algunos que no están disponibles en los registros de Percona Server:

Por cierto: las filas de notas enviadas aquí no son las mismas que las filas examinadas, mientras que en realidad deberían ser exactamente las mismas para este punto de referencia. Sin embargo, esta es la contabilidad aproximada del Plan de rendimiento en acción.

Ahora compárelo con el ejemplo de la misma consulta en el registro de consultas lentas en Percona Server

Lo que creo que es más valioso aquí es la información sobre Innodb IO que nos permite aislar instantáneamente las plantillas de aplicaciones que están vinculadas al disco IO y la información sobre Bytes Sent que nos permite ver qué consultas son responsables de generar grandes volúmenes de tráfico de red. .

Quiero que se refuerce el esquema de rendimiento para devolver los datos a algo como JSON donde para cada resumen se tienen en cuenta las primeras expectativas, ya que en realidad puede ser diferente de la demanda. Algunas preguntas pueden estar esperando el otro IO en Locks, otro podría estar vinculado por algún mutex específico. Tener información precisa sobre lo que limita el rendimiento de las preguntas específicas del tipo sería una joya.

La tercera razón usar Slow Query Log es usar marcadores de posición. La nota en la pregunta anterior tiene «SELECCIONE c DESDE sbtest DONDE id =?» lo cual no es muy conveniente: ni siquiera puedo ejecutar EXPLAIN para una consulta de este tipo para ver cuál podría ser el motivo de su lentitud. El registro contiene consultas precisas y podemos mostrar las consultas exactas en los informes (pt-query-digest y Percona Cloud Tools) o puede elegir ver solo resúmenes de consultas si no desea ver los valores de privacidad. / razones de seguridad. . Elegir la constante para una aplicación con un mal plan suele funcionar muy bien para comprobar el mal escenario.

Este puede ser un problema muy simple, porque no solo puede generar la identificación y reconstruir la aplicación, sino que para las preguntas más complicadas con muchas condiciones es prácticamente imposible reconstruir la aplicación de manera realista.

Ahora, en teoría, puedes encontrar la pregunta actual haciendo events_statements_history_long y combina los datos, pero en realidad no funciona con tasas de consulta altas, ya que es muy probable que las consultas raras no tengan una muestra disponible en la tabla de historial.

La cuarta razón está respaldado por declaraciones preparadas. Active las declaraciones preparadas y no verá la pregunta real en el resumen. Esto puede o no ser un problema para su aplicación, pero también limita la usabilidad de esta característica. No puedo contar con solo mirar events_statements_summary_by_digest para averiguar siempre qué preguntas son responsables de la mayor parte del cargo.

La quinta razón es una actuación o realmente no es una gran razón. Realmente creo que el rendimiento general de Schema es razonable para la mayoría de las cargas de trabajo. En las preguntas de referencia simples que hice:

En mi antiguo servidor tenía unos 20,2K QPS con el esquema de rendimiento desactivado y 19,4 QPS con el esquema de rendimiento habilitado, que está por encima de menos del 5 %.

Para la mayoría de las cargas de trabajo que pagan el 5% para tener una idea de lo que está pasando con el sistema, es un trato muy justo.

La sobrecarga de los registros de consultas lentas en realidad puede ser mucho mayor. El nivel moderado de detalles de «microtiempo» dio como resultado 15,1 K consultas y log_slow_verbosity = «full» elevó este valor a 11,6 K con más del 40 % de gastos generales. Tenga en cuenta que diseñé esta prueba como un escenario peor y para preguntas más complicadas, es probable que la sobrecarga sea menor (mientras que la sobrecarga con Performance Scheme puede permanecer igual o incluso aumentar según lo que pregunten las preguntas).

Algunas personas se han establecido tiempo_de_consulta_largo a algún valor distinto de cero para reducir el número de solicitudes registradas. Esta es una mala idea porque la carga de trabajo registrada será muy diferente de la real: la probabilidad de que la mayor parte de su carga provenga de preguntas simples y rápidas que no se representarán con un tiempo de demanda largo ni cero con solo valores atípicos registrados.

Una idea mucho mejor es habilitar Sampling, que está disponible en la última versión de Percona Server; de esta manera, solo se registrará una de muchas solicitudes:

Esto tendría una de cada 100 preguntas registradas al azar que deberían darle una buena idea de su carga de trabajo sin tal inclinación. Funciona bien, a menos que tenga algunas preguntas raras y muy complicadas que afectan su carga de trabajo de manera desproporcionada y que no puede ignorar para el análisis de rendimiento. Para hacer frente a esta situación hemos añadido slow_query_log_always_write_time opción a Percona Server, que le permite registrar siempre dichas solicitudes en el registro, incluso si no se seleccionaría debido al muestreo.

Permitiendo el muestreo de 1/100 consultas para esta carga de trabajo con un nivel completo de detalle, tengo 19 800 consultas que nos brindan una sobrecarga de menos del 2 %, que es incluso menor que el esquema de rendimiento y seleccionando 1/1000 consultas para registrarlas, puedo por encima de alrededor del 1%. Entonces, con Slow Query Log puedo elegir entre precisión y sobrecarga.

Desearía que el esquema de rendimiento ofreciera algo similar: en lugar de comprender qué sondas y tablas de estadísticas necesito (no todas están habilitadas automáticamente), podría optar por obtener los datos de muestra y reproducirlos con precisión en lugar de perder los datos. todos juntos.

Resumen: Hay una gran cantidad de datos en Schema Performance en MySQL 5.6 y Percona Server 5.6, aunque hay varias razones por las que es posible que ni siquiera desee descartar herramientas antiguas y probadas en función del lento registro de consultas.

PD: si te interesa ver Análisis de desempeño de la demanda en acción, únase al seminario web de Vadim el miércoles 12 de febrero. Si te lo perdiste, consulta el enlace de registro a continuación.

Author: Ing. Luis

A lo largo de conocer Windows y otros sistemas operativos me eh encontrado con diversos tipos de error, ahora brindo soluciones según mi experiencia-

Deja un comentario