He realizado algunas pruebas de rendimiento simples y parece que leer de mi RAID1 es más lento que escribir:

root@dss0:~# for i in 1 2 3; do dd if=/dev/zero of=/dev/sda bs=1048576 count=131072; done
137438953472 bytes (137 GB) copied, 192.349 s, 715 MB/s
137438953472 bytes (137 GB) copied, 192.851 s, 713 MB/s
137438953472 bytes (137 GB) copied, 193.026 s, 712 MB/s
root@dss0:~# for i in 1 2 3; do dd if=/dev/sda of=/dev/null bs=1048576 count=131072; done
137438953472 bytes (137 GB) copied, 257.201 s, 534 MB/s
137438953472 bytes (137 GB) copied, 255.522 s, 538 MB/s
137438953472 bytes (137 GB) copied, 259.945 s, 529 MB/s

Entiendo que dd no es una herramienta de prueba de rendimiento, pero este resultado sigue siendo una sorpresa.

El sistema fue construido por el proveedor y tiene una placa principal Supermicro con 16 GB de RAM. El controlador RAID es un MegaRAID 9271-8i con 1 GB de caché. Hay 8 discos SAS de 2 TByte en una placa posterior SAS-933EL1. No estoy seguro del cableado, un conector del controlador va al plano posterior SAS, el otro va a dos discos SATA que contienen el sistema operativo.

El RAID1 se configuró con este comando:

root@dss0:~# /opt/MegaRAID/MegaCli/MegaCli64 -CfgLdAdd -r1 [8:0,8:1,8:2,8:3,8:4,8:5,8:6,8:7] WB NORA Direct -a0
Adapter 0: Created VD 0
Adapter 0: Configured the Adapter!!
Exit Code: 0x00

root@dss0:~# /opt/MegaRAID/MegaCli/MegaCli64 -LDInfo -LALL -aALL
Adapter 0 -- Virtual Drive Information:
Virtual Drive: 0 (Target Id: 0)
Name                :
RAID Level          : Primary-1, Secondary-0, RAID Level Qualifier-0
Size                : 7.275 TB
Sector Size         : 512
Is VD emulated      : No
Mirror Data         : 7.275 TB
State               : Optimal
Strip Size          : 256 KB
Number Of Drives    : 8
Span Depth          : 1
Default Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
Default Access Policy: Read/Write
Current Access Policy: Read/Write
Disk Cache Policy   : Disk's Default
Encryption Type     : None
PI type: No PI
Is VD Cached: No
Exit Code: 0x00

Esperaría que el acceso de lectura sea al menos tan rápido como el acceso de escritura, tal vez incluso más rápido. La velocidad de escritura de 715 MByte / seg parece estar cerca del límite de 6 GBit de un solo conector SAS / SATA. ¿Es esto quizás un problema de configuración o cableado con el plano posterior SAS? ¿Se puede consultar la configuración del plano posterior SAS con un comando MegaRAID? Por favor avise.

Actualizar

Tal como lo expandieron poige y Peter, el rendimiento de lectura más lento de lo esperado probablemente se deba al almacenamiento en caché del subsistema de E / S de Linux.

Cuando uso la bandera directa en el comando dd obtengo

root@dss0:~# dd if=/dev/sda of=/dev/null bs=1048576 count=131072 iflag=direct
137438953472 bytes (137 GB) copied, 199.862 s, 688 MB/s

lo cual es mucho mejor pero aún 10% más lento que la velocidad de escritura. El uso de oflag = direct no afectó la velocidad de escritura.

poige tiene toda la razón sobre la caché de escritura, pero aquí hay más detalles.

dd con ceros y el uso de caché de escritura no es la forma correcta de realizar una evaluación comparativa (a menos que desee probar la caché de escritura, por supuesto, que probablemente solo sea útil para un sistema de archivos, para ver cuánto sincroniza metadatos, crea nuevos archivos, etc. ) (y probablemente dd es siempre el tipo de referencia incorrecto, pero funciona para una prueba muy básica)

Le sugiero que use dd con al menos una de las siguientes opciones:

conv=fdatasync -> this will make it flush to disk before finishing and calculating speed
oflag=direct   -> this will make it skip the OS cache but not the disk cache
conv=sync      -> more like skipping the disk cache too, but not really ... just flushing it every block or something like that.

Y no uses cero tampoco. Algunos hardware / software / firmware inteligentes pueden usar algunos accesos directos si los datos son tan predecibles como ceros. Esto es especialmente cierto si hay compresión que supongo que no estás usando. En su lugar, use un archivo aleatorio en la memoria (como / dev / shm). urandom es lento, por lo que debe escribirlo temporalmente en algún lugar para leerlo nuevamente. Crea un archivo aleatorio de 50 MB:

dd if=/dev/urandom of=/dev/shm/randfile bs=1M count=50

Lea el archivo muchas veces para escribirlo (aquí uso cat para leerlo 6 veces):

dd if=<(cat /dev/shm/randfile{,,,,,}) of= ... conv=fdatasync

rm /dev/shm/randfile

También tenga en cuenta que las lecturas de raid1 son más rápidas con operaciones paralelas, por lo que los discos se pueden usar de forma independiente. Probablemente no sea lo suficientemente inteligente como para coordinar los discos para leer diferentes partes de la misma operación con diferentes discos.

La clave para la respuesta a su pregunta es la lectura anticipada . Érase una vez, también tuve ese problema .

IOW, para un rendimiento óptimo de lectura secuencial, todos los discos deben estar permanentemente involucrados en Input.

Cuando usa ddw / o directio(vea man dd), la operación de escritura no se realiza de inmediato, sino que pasa por el caché del sistema operativo, por lo que tiene más posibilidades de involucrar todos los discos de forma secuencial y lograr el máximo rendimiento posible.