Ame sus SSD – ¡Reduzca innodb_io_capacity_max!

tu innodb_io_capacidad y innodb_io_capacity_max Los parámetros de InnoDB a menudo se malinterpretan. Como consultores, vemos, al menos todos los meses, personas que configuran esta variable en función de las especificaciones de escritura de IO de su almacenamiento. ¿Es una elección correcta? ¿Es un valor óptimo para el rendimiento? ¿Qué pasa con el nivel de uso de SSD/Flash?

Innodb_io_capacidad 101

Comencemos con lo que dice el manual sobre innodb_io_capacity:

«La variable innodb_io_capacity define la cantidad de operaciones de E/S por segundo (IOPS) disponibles para las tareas en segundo plano de InnoDB, como el flujo de páginas del grupo de búfer y la combinación de datos del búfer de cambios.«

¿Qué significa esto exactamente? Como la mayoría de los motores de bases de datos, cuando actualiza una parte de los datos en InnoDB, la actualización se realiza en la memoria y solo se escribe una breve descripción del cambio en los archivos de registro de rehacer antes de que el comando realmente regrese. La página (o páginas) afectadas en el grupo de búfer se marcan como feas. Cuando escriba más datos, aumentará la cantidad de páginas defectuosas y, en algún momento, se escribirán en el disco. Este proceso va hasta el fondo y se llama enjuagar. Innodb_io_capacity define la velocidad a la que InnoDB eliminará las páginas. Para ilustrarlo mejor, considere el siguiente gráfico:

Innodb_io_capacity variación, impacto en el flujo inactivo

Impactos de innodb_io_capacity en el flujo inactivo

Usamos la herramienta banco de sistema durante unos segundos para generar alrededor de 45000 páginas sin procesar en el grupo de búfer y luego dejar que el proceso fluya a través de tres valores de innodb_io_capacity: 300, 200 y 100. La configuración se agregó para evitar otras fuentes de escritura. Como podemos ver, el número de páginas escritas por segundo corresponde al valor innodb_io_capacity. Este tipo de lavado se llama inactivo enjuagar. tu inactivo El flujo ocurre solo cuando InnoDB no está procesando escritura. Esta es la única vez que la transmisión está dominada por innodb_io_capacity. La variable innodb_io_capacity también se usa para el flujo adaptado y el subproceso del búfer de cambio para las fusiones en segundo plano de las actualizaciones del índice secundario. En un servidor ocupado, cuando el algoritmo de flujo apropiado está activo, el innodb_io_capacity_max La variable es mucho más importante. Se está preparando una publicación de blog dedicada al interior del algoritmo de flujo adaptado de InnoDB.

¿Son malas las páginas sucias?

¿Cuáles son los pros y los contras de tener una gran cantidad de páginas malas? ¿Hay buenas razones para lavarse lo antes posible?

Si empezamos por los contras, una gran cantidad de páginas sucias aumentará el tiempo de apagado de MySQL, ya que la base de datos tendrá que lavar todas las páginas antes de registrarse. Con un poco de planificación, el problema del tiempo prolongado de apagado se puede mitigar fácilmente. Otro impacto negativo de una gran cantidad de páginas malas es el tiempo de recuperación después de un bloqueo, pero esto es bastante excepcional.

Si una página permanece sucia durante un tiempo en el grupo de búfer, tiene la posibilidad de recibir una escritura adicional antes de que se vacíe en el disco. El resultado final es una disminución de la carga de escritura. Hay esquemas y plantillas de preguntas que son más susceptibles a una reducción en la carga de escritura. Por ejemplo, si ingresa métricas recopiladas en una tabla con el siguiente esquema:

Si hay 20k dispositivos cada uno con 8 métricas, sabes que hay 160k páginas activas. Idealmente, estas páginas no deben escribirse en el disco hasta que estén llenas, de hecho, hasta la mitad, ya que son parte de un árbol b insertado en el medio.

Otro ejemplo es un usuarios tabla donde se registra la última actividad. Un esquema típico puede ser:

A menudo, solo un pequeño subconjunto de usuarios está activo a la vez, por lo que las mismas páginas se actualizarán varias veces a medida que los usuarios navegan por la aplicación. Para ilustrar este comportamiento, hicimos un pequeño experimento utilizando el diagrama anterior y actualizando activamente un subconjunto aleatorio de solo 30 000 filas en aproximadamente 6,5 millones. Un ejemplo más realista requeriría un laboratorio más capaz que esta vieja computadora portátil. Durante el experimento se utilizaron los siguientes parámetros:

Para cada ejecución, variamos innodb_io_capacity_max y calculamos el informe de actualización en la página filtrada durante 30 minutos. Nunca llegamos a una situación furiosa.

Actualizaciones de la página reveladas

Como podemos ver, cuando limitamos innodb_io_capacity_max a 100, hay alrededor de 62 actualizaciones por página descargada, mientras que en el otro extremo, con la capacidad de E/S establecida en 5000, solo hubo alrededor de 20 actualizaciones por página descargada. Esto significa que, simplemente ajustando innodb_io_capacity_max, cambiamos la carga de escritura general por un factor de tres.

Efectos del flujo excesivo en el rendimiento

Cuando una página de InnoDB está en proceso de descomprimirse en el disco, su acceso está restringido y una aplicación que necesita su contenido puede tener que esperar hasta que se complete la operación de E/S. La carga de escritura excesiva también ejerce presión sobre los recursos de almacenamiento y CPU. En el experimento anterior, donde variamos innodb_io_capacity_max, la tasa de actualización pasó de más de 6000 trx / s con innodb_io_capacity_max a 100 a menos de 5400 trx / s con innodb_io_capacity_max a 4000. Simplemente superando los valores para un rendimiento óptimo de incapacidad.

Nivel de desgaste de SSD/Flash

Pero, ¿por qué es tan importante la cantidad de escritura y qué tiene que ver con los dispositivos flash?

Los dispositivos flash son buenos, lo sabemos, pero este hito en el rendimiento tiene un inconveniente: la resistencia. Normalmente, los SSD son capaces de realizar muchas menos operaciones de escritura en cualquier sector que las unidades giratorias normales. Todo se reduce a cómo se almacenan los bits con los puertos NAND. Los bits están representados por un nivel de voltaje a través de un conjunto de compuertas y el mínimo deterioro de una compuerta, a medida que se cicla entre los valores, afecta estos niveles de voltaje. Con el tiempo, un elemento de memoria ya no alcanza su voltaje adecuado. Los dispositivos flash más baratos almacenan más bits por conjunto de puertos por celda de almacenamiento, por lo que se ven más afectados por el deterioro de los niveles de voltaje. Los SSD también tienen más o menos celdas de almacenamiento de repuesto para reparar las rotas.

Veamos la resistencia de algunos SSD. Elegimos algunos modelos del sitio web de Intel principalmente porque se proporcionan los precios estimados.

Modelo Escribe Cortar Resistencia (ciclo) precio
Optano DC P4800X Compañía 1,5 TB 112,000 $ 4,975
CC P4610 Compañía 1,6 TB 7,840 $ 467
545S Consumidor 512 GB 576 $ 120

La resistencia se expresa en ciclos de escritura completos, la cantidad de veces que el dispositivo se puede sobrescribir por completo. La resistencia es una de las principales variables que afectan el precio. Los SSD de calidad de la empresa tienen una mayor resistencia que los de consumo. La serie Optane se encuentra en el extremo superior de la oferta de la compañía.

Dispositivos como el CC P4610 son bastante comunes. Las especificaciones de la unidad en la tabla anterior muestran un tiempo de escritura total de 12,25 PB (7840 escrituras completas del dispositivo) y la capacidad de realizar 640 000 lecturas de IOPS y aproximadamente 200 000 escrituras de IOPS. Asumir una vida útil del servidor de cinco años significa que el ancho de banda de escritura promedio debe ser inferior a:

12,25 PB * 1024^3 MB/PB/(5 años * 365 d/a * 24 h/d * 3600 s/h) ~ 83 MB/seg.

El impacto del factor de relleno

Entonces, en teoría, puede escribir a 83 MB / seg durante cinco años. Esto es muy alto pero… se trata de un dispositivo vacío. Si hay un conjunto de datos estáticos, como datos antiguos que nadie quiere eliminar, que llenan el 75% del SSD, la situación es muy diferente. Ahora, solo el 25 % de la unidad recibe todos los scripts y las celdas de almacenamiento se ciclan mucho más rápido. Lo hemos reducido a un promedio de alrededor de 21 MB/seg en cinco años. Todavía es un ancho de banda decente, pero cae en casos de uso más realistas.

La siguiente figura muestra el ancho de banda de escritura promedio requerido para alcanzar la especificación de resistencia SSD en función del factor de llenado. Con los SSD, si los discos están bastante llenos, es una buena idea borrar los datos periódicamente, quizás cada año o cada 6 meses, y recargarlos. Este proceso reemplaza los datos y ayuda a distribuir el voltaje a todas las celdas de almacenamiento. Si está utilizando Percona XtraDB Cluster, esto es equivalente a activar un SST completo después de eliminar el conjunto de datos y posiblemente ejecutarlo. fstrim si el sistema de archivos no está montado con el descarte opción.

Anote el ancho de banda necesario para grabar un SSD

Ahora, en términos de carga de escritura de InnoDB, debido a cosas como el búfer de escritura doble, el registro de rehacer, el registro de deshacer y el registro binario, cuando InnoDB escribe una página de 16 KB en el disco, la cantidad actual de datos escritos es mayor, entre 32 KB. es de 48 KB. Esta estimación depende en gran medida del diseño y la carga de trabajo, pero como estimación aproximada, podemos estimar 36 KB escritos por página lavada.

A menudo vemos valores muy altos para ello. tanto innodb_io_capacity es innodb_io_capacity_max, ya que las personas miran las especificaciones de sus SSD y establecen un número muy alto. Los valores de varias decenas de miles son comunes; incluso hemos visto más de 100k algunas veces. Valores tan altos conducen a un flujo de InnoDB agresivo, mucho más de lo necesario. Hay muy pocas páginas defectuosas en el grupo de búfer y el rendimiento se degrada. El valor de edad del punto de control de InnoDB es probablemente muy cercano innodb_adaptive_flushing_lwm veces el valor máximo de edad del punto de control.

En un servidor moderadamente ocupado, se pueden lograr fácilmente tasas de flujo sostenido de InnoDB de 2000 páginas por segundo. Dada nuestra estimación de 36 KB escritos por página descargada, dicha velocidad de flujo produce un ancho de banda de escritura de 70 MB/s. Mirando la figura anterior, si el SSD utilizado tiene especificaciones similares y está lleno en más del 75 %, no durará 5 años; más bien, probablemente menos de un año y medio.

Conclusiones

Esta publicación intenta arrojar algo de luz sobre un problema común que observamos con mucha más frecuencia de la que nos gustaría. De hecho, nos sorprende ver a muchas personas que recomiendan aumentar la configuración de la capacidad de IO prácticamente de forma inmediata en lugar de prestar atención a algunos otros parámetros.

Por lo tanto, mantenga la configuración de io_capacity todo el tiempo que necesite. ¡Sus SSD se lo agradecerá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