La operación de mkfs tarda mucho en el software Linux Raid 5

He configurado un nivel 5 de incursión de software de Linux que consiste en discos de 4 * 2 TB. La matriz de discos se creó con un tamaño de banda de 64k y ningún otro parámetro de configuración. Después de la reconstrucción inicial, intenté crear un sistema de archivos y este paso lleva mucho tiempo (aproximadamente media hora o más). Traté de crear un sistema de archivos xfs y ext3, ambos tomaron mucho tiempo, con mkfs.ext3 Observé el siguiente comportamiento, que podría ser útil:

escribir tablas de inodo se ejecuta rápidamente hasta llegar a 1053 (~ 1 segundo), luego escribe aproximadamente 50, espera dos segundos, luego se escriben los siguientes 50 (según la pantalla de la consola)
cuando trato de cancelar la operación con Control + C se cuelga durante medio minuto antes de que se cancele realmente

El rendimiento de los discos individualmente es muy bueno, he ejecutado bonnie ++ en cada uno por separado con valores de escritura / lectura de alrededor de 95 / 110MB / s. Incluso cuando ejecuto bonnie ++ en cada unidad en paralelo, los valores solo se reducen en aproximadamente 10 MB. Por lo tanto, estoy excluyendo la programación de hardware / E / S en general como fuente de problemas.

Probé diferentes parámetros de configuración para stripe_cache_size y readahead size sin éxito, pero no creo que sean tan relevantes para la operación de creación del sistema de archivos.

Los detalles del servidor:

Servidor Linux 2.6.35-27-genérico # 48-Ubuntu SMP x86_64 GNU / Linux
mdadm - v2.6.7.1

¿Alguien tiene una sugerencia sobre cómo depurar esto más?

— Elmar Weber
fuente

Respuestas:

Estoy de acuerdo, que puede estar relacionado con la alineación de bandas. Desde mi experiencia, la creación de XFS no alineado en 3 * 2TB RAID-0 tarda ~ 5 minutos, pero si está alineado con el tamaño de la franja, es ~ 10-15 segundos. Aquí hay un comando para alinear XFS a un tamaño de banda de 256 KB:

mkfs.xfs -l internal,lazy-count=1,sunit=512 -d agsize=64g,sunit=512,swidth=1536 -b size=4096 /dev/vg10/lv00

Por cierto, el ancho de banda en mi caso es de 3 unidades, que será lo mismo para ti con 4 unidades pero en raid-5.

Obviamente, esto también mejora el rendimiento de FS, por lo que es mejor mantenerlo alineado.

— dtoubelis
fuente

Hola, esto no hizo ninguna diferencia, lo intenté: time mkfs.xfs -l sunit=128 -d agsize=64g,sunit=128,swidth=512 -b size=4096 /dev/md0 -fque tomó aproximadamente el mismo tiempo que mkfs sin ningún parámetro

— Elmar Weber

Estoy ejecutando bonnie ++, así que vea si hace alguna diferencia de rendimiento durante la operación. por cierto: ¿hay alguna razón para el parámetro agsize? Leí la página de manual pero no pude deducir el beneficio de establecerla en un valor.

— Elmar Weber

(por cierto: el comando anterior era incorrecto, el ancho correcto era 384)

— Elmar Weber

No obtuve ningún aumento de rendimiento en mkfs, pero el rendimiento general medido con bonnie ++ es mucho mejor: las operaciones de creación / eliminación de archivos son aproximadamente 4 veces mejores que antes y la velocidad de escritura secuencial es de aproximadamente un 15%. Muchas gracias.

— Elmar Weber

agsize no es realmente necesario aquí: mkfs lo calculará automáticamente (probablemente dividiendo el tamaño del volumen por la cantidad de CPU lógicas). Es sobrante de mi propia configuración: creé este volumen con algunas expectativas para futuros cambios de configuración.

— dtoubelis

Sospecho que te encuentras con el típico problema de escritura pequeña RAID5. Para escrituras por debajo del tamaño de una franja, tiene que hacer una lectura-modificación-escritura tanto para los datos como para la paridad. Si la escritura es del mismo tamaño que la banda, simplemente puede sobrescribir la paridad, ya que sabe cuál es el valor y no tiene que volver a calcularlo.

— malcolmpdx
fuente

Tendría sentido, ¿estoy viendo esto correctamente ?: De acuerdo con la salida mkfs.ext3 escribe alrededor de 25 tablas de inodo por segundo, supongo que son más pequeñas que 64k durante la creación inicial, por lo que se escribe una banda de 64k. Esto significaría una escritura de 16k en cada disco, por lo que en conjunto 25 escrituras aleatorias de 16k por segundo, con un tamaño de sector de 4kb, esto significa 100 operaciones de E / S aleatorias por segundo, que es lo que mostró Bonnie ++.

— Elmar Weber

Coincide con el resultado de bonnie ++ en la incursión real, 335 MB de lectura y 310 MB de escritura, sin embargo, la creación y eliminación de archivos es solo 1/4 del rendimiento de un solo disco.

— Elmar Weber

Su mkfs y el rendimiento posterior del sistema de archivos podrían mejorar si especifica el ancho de banda y el ancho de banda al crear el sistema de archivos. Si está utilizando los bloques predeterminados de 4k, su zancada es 16 (banda RAID de 64k dividida por el bloque del sistema de archivos de 4k) y su ancho de banda es 48 (zancada del sistema de archivos de 16 multiplicado por los 3 discos de datos en su matriz).

mkfs.ext3 -E stride=16 stripe-width=48 /dev/your_raid_device

— Sciurus
fuente