Alta espera de E / S: ¿cómo determinar la causa raíz?

10

Tengo una instancia de MySQL en dos servidores dedicados. Uno para la producción, el otro para la plataforma de prueba.

Los 2 servidores son bastante iguales, la única diferencia es el controlador RAID y el volumen virtual (HD son los mismos). En la producción, hay un controlador RAID HW dedicado y un volumen RAID 10. Por otro lado, el controlador RAID parece ser un software (Lenovo ThinkServer RAID 110i) y el volumen es RAID 5.

Notamos que durante las confirmaciones de MySQL, tenemos un alto iowait:

while true; do date; ps auxf | awk '{if($8=="D") print $0;}'; sleep 1; done
root     26661  0.0  0.0      0     0 ?        D    Jun09   5:41  \_ [jbd2/dm-14-8]
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:37 CEST 2015
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:38 CEST 2015
root      1474  0.0  0.0      0     0 ?        D    Jun04   0:23  \_ [jbd2/dm-5-8]
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:39 CEST 2015
Thu Jun 18 13:49:40 CEST 2015
root      1474  0.0  0.0      0     0 ?        D    Jun04   0:23  \_ [jbd2/dm-5-8]
root      1478  0.0  0.0      0     0 ?        D    Jun04   0:03  \_ [jbd2/dm-7-8]
root     26661  0.0  0.0      0     0 ?        D    Jun09   5:41  \_ [jbd2/dm-14-8]

dm-10-8 y dm-14-8 están relacionados con particiones de bases de datos.

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  3 240904 809656 572624 7114416    0    0    59  1681 2002 5141  3  1 67 30  0
 0  4 240880 809656 572632 7114604    0    0   139  2069 2090 4985  3  1 67 29  0
 1  2 240880 809284 572636 7114676    0    0    27  2159 2253 4247  2  1 72 25  0
 5  2 240880 809408 572656 7114820    0    0    27  2404 2254 5350  3  1 69 27  0

Sospecho que el controlador de banda, ¿cómo puedo estar seguro?

Bob Sauvage
fuente
Quizás fuera de tema: ¿Pero por qué RAID5 en una base de datos? Mala idea debido a la brecha de escritura. HW con BBU mitiga esto un poco, pero RAID 5 es básicamente bueno para leer, no para escribir pequeñas transacciones.
Hennes
Porque no tenía otra opción ... RAID 10 no era compatible con este controlador RAID (con mi versión de RHEL) ...
Bob Sauvage
@BobSauvage cualquier progreso?
Huygens
para ser claros: ¿io-wait incluye también esperar en los descriptores de archivo no proporcionados por el almacenamiento masivo? como enchufes ...
Massimo

Respuestas:

7

Mi respuesta tenía 2 partes: investigación del controlador del dispositivo de bloque; y optimización que vale la pena mirar con su caso de uso. Pero eliminé la última parte, ya que se informó que puede conducir a la pérdida de datos. Ver comentarios.

Investigación de hardware

Comprendí que para la misma aplicación, pero en 2 conjuntos diferentes de hardware, el rendimiento es muy diferente y le gustaría entender por qué. Por lo tanto, propongo primero un medio para ayudarlo a encontrar una respuesta para el "por qué".

Para el rendimiento, a menudo me refiero al Mapa de rendimiento de Linux proporcionado por Brendan Gregg en su blog. Se puede ver que para el nivel bajo (más cercano al hardware) una herramienta como blktracesería perfecta.

Sin saber realmente esta herramienta, busqué y encontré este interesante artículo sobre blktrace de Marc Brooker. Básicamente sugiere lo siguiente: realizar un seguimiento de E / S usando blktrace; usando la herramienta btt para extraer información de este rastro. Eso sería algo como esto (para una traza de 30 s):

# blktrace -w 30 -d /dev/dm-10-8 -o dm-10-8
# blkparse -d blkmerged.out dm-10-8*
# btt -i blkmerged.out | less

La salida puede ser bastante larga, pero busque entradas D2C. Le dará una idea del tiempo que toma para que una E / S entregada al controlador del dispositivo sea informada como completada por este controlador.

Ejemplo de salida ( dnf upgradeejecutándose en una VM VirtualBox en mi computadora portátil ocupada):

            ALL           MIN           AVG           MAX           N
--------------- ------------- ------------- ------------- -----------

...
D2C               0.000046515   0.045781696   3.940577359       11713
...

¡Muestra un promedio decepcionante de 45 ms por E / S con hasta 3,94 s para el peor de los casos!

Para obtener más formas de utilizar blktrace para realizar esta investigación, lea el artículo de Marc Brooker, muy instructivo.

Huygens
fuente
La publicación de blog de Percona a la que se hace referencia en el ajuste de respuesta para mejorar el rendimiento de innodb se ha actualizado con: Actualización: no haga esto, ¡se ha demostrado que esto corrompe los datos!
vkats
@vkats muchas gracias. He actualizado la respuesta para eliminar la sugerencia y el artículo.
Huygens
1

El proceso jbd2 es para el diario ext4. Es lógico que el sistema de archivos necesite escribir en el diario durante las confirmaciones de mysql, esto no debería ser motivo de preocupación. La cantidad de carga causada por jbd está influenciada por los parámetros de montaje para las particiones dm-10-8 y dm-14-8. Probablemente sea deseable tener un registro muy conservador en la partición de la base de datos para asegurarse de que su base de datos no se corrompa si algo sucede y su servidor se reinicia accidentalmente. Puede seleccionar otras opciones de montaje de diario en el entorno de prueba solo para comparar.

ludvik02
fuente
mi jbd2 / dm-2-8 parece todo el tiempo alrededor de 8.5% en iotop, pero ... No creo que sea problemático ya que no hay lectura de disco, y la escritura total del disco es de 35mb después de 1 hora. por cierto, en / dev hay a lo sumo dm-2 (que -8 no tengo idea de dónde es ..)
Aquarius Power