Tenga en cuenta los problemas de rendimiento de E/S de disco cuando ejecute EXT4

Recientemente, en Percona Live Europe 2019, Dimitri Kravchuk de Oracle dijo que observó una caída incierta en el rendimiento de MySQL en un sistema de archivos ext4 con el último kernel de Linux. Decidí comprobar este caso por mi cuenta y descubrí que realmente, comenzando con el kernel de Linux 4.9, hay algunos casos con caídas notables (hasta 2x) de rendimiento para el sistema de archivos ext4 directamente i/o.

Entonces, ¿qué tiene de malo ext4? Comenzó en 2016 con un parche que se envió al kernel 4.9: «ext4: permite lecturas DIO paralelas». El propósito de este parche era ayudar a mejorar la legibilidad y/o la lectura directa. Sin embargo, junto con las mejoras en las cargas de trabajo de lectura pura, también introdujo la regresión en escenarios de lectura/escritura aleatorios mixtos intensos. Y es bastante extraño, pero este problema no se notó durante 3 años. Solo este verano ha habido un retroceso de rendimiento reportado y discutido en LKML. Como resultado de esta discusión, hay una intento para arreglar, pero según mi conocimiento actual, la solución se enviará solo a los próximos kernels 5.4 / 5.5. A continuación, describiré cómo se ve esta regresión, cómo afecta las cargas de trabajo de MySQL y qué soluciones podemos aplicar para mitigar este problema.

Regresión de rendimiento ext4

Comenzamos a definir el propósito de esta regresión de rendimiento de ext4. Solo tendrá impacto si la instalación/carga de trabajo cumple con las siguientes condiciones:
– ssd / nvme rápido
– núcleo linux> = 4.9
– los archivos residen en el sistema de archivos ext4
– archivos abiertos con el indicador O_DIRECT
– al menos algunas E / S deben ser síncronas

En el informe original a LKML, el problema se observó/reprodujo con un escenario mixto de lectura/escritura aleatoria con E/S sincronizada y O_DIRECT. Pero, ¿cómo lidias con estos factores con MySQL? Los únicos archivos abiertos por InnoDB en modo O_DIRECT son tablespaces (archivos * .ibd), y la plantilla de E/S para tablespaces consta de las siguientes operaciones:

– lee datos ibd sincrónicamente
– escribir datos ibd de forma asíncrona
– posix_allocate para extender el archivo tablespace seguido de un script síncrono
– sincronizar

También hay E/S adicionales de los archivos de registro WAL:

– escribe datos en archivos de registro de forma síncrona
– sincronizar

Entonces, en el caso de los espacios de tabla de InnoDB que están abiertos con O_DIRECT, tenemos una combinación de lectura síncrona y escritura asíncrona y resulta que tal combinación con escritura síncrona en el archivo de registro de innodb es suficiente para causar una regresión de rendimiento notable. Dibujé la carga de trabajo para la herramienta fio (ver más abajo) que simula el modelo de acceso de E/S para InnoDB y la ejecuté para unidades SSD y NVMe para kernels de Linux 4.4.0, 5.3.0 y 5.3.0 con arreglo de escalabilidad ext4 . .

resultados fio en el gráfico:

Comentarios:

– para la unidad SATA/SSD casi no hay diferencia en el rendimiento, y solo en 16 cables vemos una caída de lectura para ext4/kernel-5.3.0. Para ext4/kernel-5.3.0 montado con dioread_nolock (que permite correcciones de escalabilidad), vemos que IOPS regresa y también se ve mejor.
– para la unidad NVMe, la situación se ve muy diferente – hasta 8 cables i/o IOPS para lectura y escritura son más/menos similares, pero después del aumento de la presión en la i/o vemos un pico notable para las escrituras son un caída similar para las lecturas. Y también el montaje ext4 con dioread_nolock ayuda a obtener el mismo rendimiento que los núcleos <4.9.

Se pueden encontrar datos de rendimiento similares para el problema original informado a LKML (con más detalles y análisis) en el parche en sí.

Cómo afecta a MySQL

O_DIRECTO

Ahora revisaremos el impacto de este problema en una carga de trabajo OLTP_RW/sysbench vinculada a IO en modo O_DIRECT. Hice una prueba para la siguiente instalación:

– sistema de archivos: xfs, ext4 / default, ext4 / dioread_nolock
– unidad: SATA / SSD y NVMe
– núcleos: 4.4.0, 5.3.0, 5.3.0 + ilock_fix

Observaciones

– en el caso de SATA/SSD, el problema de escalabilidad ext4 tiene un impacto en la tasa de tps después de 256 hilos y la caída es del 10-15%
– en el caso de NVMe y ext4 regular con kernel 5.3.0, provoca una caída en el rendimiento de ~ 30-80%. Si aplicamos un montaje fijo ext4 con dioread_nolock o usando xfs, el rendimiento se ve bien.

O_DSYNC

Como la regresión ext4 afecta a O_DIRECT, reemplazamos O_DIRECT con O_DSYNC y observamos los resultados de la misma carga de trabajo sysbench/OLTP_RW en kernel 5.3.0:

Nota: Para que los resultados entre O_DIRECT y O_DSYNC sean comparables, tengo una memoria disponible limitada para la instancia de MySQL de cgroup.

Comentarios:

En el caso de O_DSYNC y ext4 normales, el rendimiento es solo un 10 % inferior al de O_DIRECT/ext4/dioread_nolock y O_DIRECT/xfs y ~35 % superior al de O_DIRECT/ext4. Esto significa que O_DSYNC se puede usar como una solución alternativa cuando tiene almacenamiento rápido y ext4 como sistema de archivos, pero no puede cambiar a xfs o actualizar el kernel.

Conclusiones / soluciones

Si su carga de trabajo/configuración se ve afectada, existen las siguientes opciones que puede considerar como alternativa:

– downgrade y kernel de linux a 4.8
– Instale el kernel 5.3.0 con corrección y monte ext4 con la opción dioread_nolock
– si O_DIRECT es importante, cambie al sistema de archivos xfs
– Si cambiar el sistema de archivos no es una opción, reemplace O_DIRECT con O_DSYNC + cgroup

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