6 votos

¿Por qué mdadm escribe inútilmente lento cuando está montado sincrónicamente?

Tengo una matriz de 6 discos raid6 mdadm a la que me gustaría comparar las escrituras:

root@ubuntu:~# cat /proc/mdstat 
Personalities : [raid6] [raid5] [raid4] 
md0 : active raid6 sda[0] sdf[5] sde[4] sdd[3] sdc[2] sdb[1]
      1953545984 blocks level 6, 64k chunk, algorithm 2 [6/6] [UUUUUU]

Los puntos de referencia pueden ser inexactos debido al caché - por ejemplo, note que la velocidad de escritura aquí es más alta de lo que debería ser:

root@ubuntu:/mnt/raid6# dd if=/dev/zero of=delme bs=1M count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.276026 s, 380 MB/s

Ahora podemos deshabilitar cada caché de disco con bastante facilidad:

root@ubuntu:~# hdparm -W0 /dev/sd*

/dev/sda:
 setting drive write-caching to 0 (off)
 write-caching =  0 (off)

/dev/sdb:
 setting drive write-caching to 0 (off)
 write-caching =  0 (off)

/dev/sdc:
 setting drive write-caching to 0 (off)
 write-caching =  0 (off)

/dev/sdd:
 setting drive write-caching to 0 (off)
 write-caching =  0 (off)

/dev/sde:
 setting drive write-caching to 0 (off)
 write-caching =  0 (off)

/dev/sdf:
 setting drive write-caching to 0 (off)
 write-caching =  0 (off)

Pero todavía hay caching de Linux:

root@ubuntu:/mnt/raid6# dd if=/dev/zero of=delme bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.00566339 s, 1.9 GB/s

Para desactivar el cacheo de Linux, podemos montar el sistema de archivos sincrónicamente:

mount -o remount,sync /mnt/raid6

Pero después de esto los escritos se convierten camino más lento de lo que debería ser:

root@ubuntu:/mnt/raid6# dd if=/dev/zero of=delme bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 23.3311 s, 449 kB/s

Es como si mdadm necesitara montajes asíncronos para funcionar. ¿Qué está pasando aquí?

2voto

Peter Puntos 625

Cita del interrogador:

Pero todavía hay caching de Linux:

root@ubuntu:/mnt/raid6# dd if=/dev/zero of=delme bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.00566339 s, 1.9 GB/s

Para desactivar el cacheo de Linux, podemos montar el sistema de archivos sincrónicamente:

mount -o remount,sync /mnt/raid6

Eso no es del todo correcto... la sincronización no deshabilita el caching como quieres en un benchmark. Hace que cada escritura resulte en un comando "sync", lo que significa vaciar la caché hasta el disco.

Aquí hay un servidor, para explicarlo mejor:

$ dd if=/dev/zero of=testfile bs=1M count=500
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 0.183744 s, 2.9 GB/s

$ dd if=/dev/zero of=testfile bs=1M count=500 conv=fdatasync
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 5.22062 s, 100 MB/s

conv=fdatasync simplemente significa descarga después de la escritura, y te dice la hora incluyendo esa descarga. Alternativamente, puedes hacerlo:

$ time ( dd if=/dev/zero of=testfile bs=1M count=500 ; sync )
500+0 records in
500+0 records out
524288000 bytes (524 MB) copied, 0.202687 s, 2.6 GB/s

real    0m2.950s
user    0m0.007s
sys     0m0.339s

Y luego calcula los MB/s de los 2,95s en tiempo real en vez de los 0,2s de arriba. Pero eso es más feo, y más trabajo, ya que las estadísticas impresas por dd no incluyen la sincronización.

Si usaras "sync", eliminarías cada escritura... ...tal vez eso signifique cada bloque, lo cual iría muy lento. "sync" sólo debería ser usado en sistemas muy estrictos, por ejemplo, bases de datos donde la pérdida de una sola transacción debido a una falla en el disco es inaceptable (por ejemplo, si transfiero un billón de dólares de mi cuenta bancaria a la suya, y el sistema se cae, y de repente usted tiene el dinero pero yo también).

Aquí hay otra explicación con opciones adicionales, una que leí hace mucho tiempo. http://romanrm.ru/en/dd-benchmark

Y una nota más: su referencia que está haciendo de esta manera es totalmente válida en mi opinión, aunque no es válida en las opiniones de muchos otros. Pero no es una prueba de la vida real. Es una escritura secuencial de un solo hilo. Si tu caso de uso en la vida real es así, por ejemplo, enviando algunos archivos grandes a través de la red, entonces puede ser un buen punto de referencia. Si tu caso de uso es diferente, por ejemplo, un servidor ftp con 500 personas subiendo pequeños archivos al mismo tiempo, entonces no es muy bueno.

Y también, deberías usar un archivo generado aleatoriamente en la RAM para obtener mejores resultados. Algunos sistemas de archivos son demasiado inteligentes cuando los alimentas con ceros. Por ejemplo, en Linux usando el sistema de archivos ram tmpfs que está montado en /dev/. (y en algunos sistemas /dev/random o /dev/urandom es lento así que usa el otro... Olvidé cuál, pero en cualquiera de los dos serán mucho menos que la RAM así que no lo uses directamente)

dd if=/dev/random of=/dev/shm/randfile bs=1M count=500
dd if=/dev/shm/randfile bs=1M count=500 conv=fdatasync

1voto

tmehlinger Puntos 156

El rendimiento es dramáticamente peor porque la escritura sincrónica obliga al cálculo de paridad a martillar los discos.

En general, la paridad de computación y escritura es un proceso relativamente lento, especialmente con RAID 6. En su caso, MD no sólo tiene que fragmentar los datos en cuatro trozos, sino que luego calcula dos trozos de paridad para cada franja. Para mejorar el rendimiento, las implementaciones de RAID (incluyendo md) almacenarán en caché las franjas utilizadas recientemente en la memoria para comparar los datos a escribir con los datos existentes y volver a calcular rápidamente la paridad al escribir. Si se escriben nuevos datos en una franja almacenada en caché, puede comparar, fragmentar y volver a calcular la paridad sin tocar el disco, para luego eliminarlos más tarde. Has creado una situación en la que md siempre pierde la caché, en cuyo caso tiene que leer la banda del disco, comparar los datos, fragmentar los nuevos datos, volver a calcular la paridad y luego descargar la nueva banda directamente al disco. Lo que requeriría cero lecturas y escrituras desde/hacia el disco en un golpe de caché se convierte en seis lecturas y seis escrituras por cada raya escrita.

De acuerdo, la diferencia de rendimiento que has observado es enorme (1,9 GB/s frente a 449 KB/s), pero creo que todo se explica por la cantidad de trabajo que está haciendo MD para mantener la integridad de los datos.

Este éxito de rendimiento puede verse agravado por la forma en que tienes los discos dispuestos... si los tienes todos en un solo mando, esa cantidad extra de lectura y escritura paralizará el rendimiento.

0voto

Nils Puntos 5486

¿Puede decirnos cómo están hechos sus 6 discos? Me suena como si fueran parte de SAN/DAS, sean cuales sean los objetivos, que probablemente consistan en los mismos discos físicos (así que si los 6 residen en el mismo disco esto degradará el rendimiento en comparación con un solo disco por 6).

Echa un vistazo a este enlace a anwerleaks.com.

Entonces, ¿cómo has configurado tu mapa de bits?

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: