¿Cómo predecir los puntos de inflexión de MySQL?

Question

Trabajo en una gran aplicación web que utiliza una base de datos MySQL 5.0 con tablas InnoDB. Dos veces en los últimos meses, hemos experimentado el siguiente escenario:

1. El servidor de base de datos funciona bien durante semanas, con poca carga y pocas consultas lentas.
2. Una consulta frecuente que se ejecutó rápidamente de repente comenzará a ejecutarse muy lentamente.
3. Picos de carga en la base de datos y el sitio se cuelga.

La solución en ambos casos fue encontrar la consulta lenta en el registro lento de consultas y crear un nuevo índice en la tabla para acelerarlo. Después de aplicar el índice, el rendimiento de la base de datos volvió a ser normal.

Lo que es más frustrante es que, en ambos casos, no tuvimos ninguna advertencia sobre la inminente fatalidad; todos nuestros sistemas de monitoreo (por ejemplo, gráficos de carga del sistema, uso de CPU, tasas de ejecución de consultas, consultas lentas) nos dijeron que el servidor de la base de datos estaba en buen estado.

Pregunta n. ° 1: ¿Cómo podemos predecir este tipo de puntos de inflexión o evitarlos por completo?

Una cosa que no estamos haciendo con regularidad es ejecutar OPTIMIZE TABLE o ANALYZE TABLE. Nos ha costado encontrar una buena regla general sobre la frecuencia (si es que lo hemos hecho alguna vez) para hacer estas cosas manualmente. (Dado que estos comandos LOCK tablas, no queremos ejecutarlos indiscriminadamente.) ¿Estos escenarios suenan como el resultado de tablas no optimizadas?

Pregunta n. ° 2: ¿Deberíamos ejecutar OPTIMIZE o ANALYZE manualmente? Si es así, ¿con qué frecuencia?

Más detalles sobre la aplicación: el patrón de uso de la base de datos es aproximadamente 95% lecturas, 5% escrituras; la base de datos ejecuta alrededor de 300 consultas/segundo; la tabla utilizada en las consultas lentas fue la misma en ambos casos y tiene cientos de miles de registros.

Answer 1

Use slow query log que lo ayudará a reducir las consultas que desea optimizar.

Para consultas de tiempo crítico, a veces es mejor mantener un plan estable mediante sugerencias.

Answer 2

El Blog de rendimiento de MySQL es un recurso fantástico. A saber, la publicación this cubre los aspectos básicos para ajustar correctamente los parámetros específicos de InnoDB.

También he encontrado que la versión en PDF del MySQL Reference Manual es esencial. Chapter 7 covers general optimization y section 7.5 cubre optimizaciones específicas del servidor con las que puede jugar.

Desde el sonido de su servidor, el query cache puede ser de valor INMENSO para usted.

El manual de referencia también le ofrece algunos detalles excelentes sobre consultas lentas, cachés, optimización de consultas e incluso análisis de búsqueda de discos con índices.

Puede valer la pena ver la replicación multimaestro, lo que le permite bloquear un servidor por completo y ejecutar OPTIMIZE/ANALYZE, sin tener un impacto en el rendimiento (ya que el 95% de las consultas son lecturas, el otro servidor podría administrar las escrituras muy bien).

Sección 12.5.2.5 cubre OPTIMIZE TABLE en detalle, y 12.5.2.1 cubre ANALYZE TABLE en detalle.

actualización para su ediciones/énfasis:

Pregunta # 2 es fácil de responder. Desde el manual de referencia:

Optimizar:

OPTIMIZE TABLE se debe utilizar si ha eliminado una gran parte de la mesa o si se han realizado muchos cambios en una tabla con registros de longitud variable. [...] Puede usar OPTIMIZE TABLE para reclamar el espacio no utilizado y desfragmentar la tabla de datos.

y analizar:

comando analiza y almacena la distribución de claves para una mesa. [...] MySQL usa la distribución de claves almacenadas para decidir el orden en el que se unirán las tablas cuando realice una combinación en algo que no sea una constante. Además, las distribuciones de claves se pueden usar al decidir qué índices usar para una tabla específica dentro de una consulta.

OPTIMIZE es bueno para funcionar cuando tienes el tiempo libre. MySQL optimiza bien alrededor de las filas eliminadas, pero si va y elimina 20 GB de datos de una tabla, es puede ser una buena idea para ejecutar esto. Definitivamente no es necesario para un buen rendimiento en la mayoría de los casos.

ANALYZE es mucho más crítico. Como se mencionó, tener los datos de tablas necesarios para MySQL (provistos con ANALYZE) es muy importante cuando se trata de casi cualquier consulta. Es algo que debe ejecutarse sobre una base común.

Pregunta n. ° es un truco más. Yo miraba el servidor con mucho cuidado cuando esto sucede, es decir, la E/S de disco. Mi apuesta sería que su servidor está agotando su caché o los cachés (InnoDB). En cualquier caso, puede ser consulta, ajuste o relacionado con la carga. Las tablas no optimizadas podrían causar esto. Como se mencionó, ejecutar ANALYZE puede ayudar inmensamente al rendimiento, y probablemente también ayude.

Answer 3

Parece que tiene una situación frustrante y tal vez no es el mejor proceso de revisión de código y entorno de desarrollo.

Cada vez que agrega una nueva consulta a su código, debe verificar que tenga listos los índices adecuados y agregarlos con la publicación del código.

Si no lo hace, su segunda opción es monitorear constantemente el registro lento de consultas y luego ir a vencer a los desarrolladores; Quiero decir agregar el índice.

Existe una opción para habilitar el registro de consultas que no utilizaron un índice que podría ser útil para usted.

Si hay algunas consultas que "funcionan y dejan de funcionar" (pero están "usando e indexando"), es probable que la consulta no fuera buena en primer lugar (baja cardinalidad en el índice; unión ineficiente; ...) y se aplicaría la primera regla de evaluar cuidadosamente la consulta cuando se agrega.

Para la pregunta n. ° 2: OnnoDB "analizar tabla" es, básicamente, libre de ejecutar, por lo que si tiene un mal rendimiento de la unión, no hace daño ejecutarlo. A menos que el equilibrio de las teclas de la tabla esté cambiando mucho, es poco probable que ayude. Casi siempre se reduce a malas consultas."optimizar tabla" reconstruye la tabla InnoDB; en mi experiencia, es relativamente raro que ayude lo suficiente para que valga la pena tener la tabla no disponible durante todo el tiempo (o hacer el failover maestro maestro mientras se está ejecutando).

Answer 4

No he encontrado ninguna forma de predecir los "puntos de inflexión" de MySQL, y me he encontrado con algunos.

Habiendo dicho eso, he encontrado que los puntos de inflexión están relacionados con el tamaño de la mesa. Pero no solo el tamaño de tabla sin formato, sino el tamaño del "área de interés" para una consulta. Por ejemplo, en una tabla de más de 3 millones de filas y alrededor de 40 columnas, alrededor de tres cuartos de enteros, la mayoría de las consultas que seleccionarían fácilmente una parte de ellas según los índices son rápidas. Sin embargo, cuando un valor en una consulta en una columna indexada significa que dos tercios de las filas son ahora "interesantes", la consulta ahora es 5 veces más lenta que lo normal. Lección: intente organizar sus datos para que no sea necesario un escaneo.

Sin embargo, tal comportamiento ahora le da un tamaño que debe buscar. Este tamaño dependerá en gran medida de la configuración del servidor, las variables del servidor MySQL y el esquema y los datos de la tabla.

De manera similar, he visto que las consultas de informes se ejecutan en un tiempo razonable (~ 45 segundos) si el período es de dos semanas, pero demoran media hora si el período se extiende a cuatro semanas.