Fiz alguns testes simples de desempenho e parece que a leitura do meu RAID1 é mais lenta que a escrita:

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

Entendo que o dd não é uma ferramenta de teste de desempenho, mas esse resultado ainda é uma surpresa.

O sistema foi construído pelo fornecedor e possui uma placa principal Supermicro com 16 GByte de RAM. O controlador RAID é um MegaRAID 9271-8i com cache de 1 GByte. Existem 8 discos SAS de 2 TByte em um backplane SAS-933EL1. Não tenho certeza do cabeamento, um conector do controlador vai para o backplane SAS e o outro para dois discos SATA que mantêm o sistema operacional.

O RAID1 foi configurado com 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

Eu esperaria que o acesso de leitura seja pelo menos tão rápido quanto o acesso de gravação, talvez até mais rápido. A velocidade de gravação de 715 MByte / s parece estar próxima do limite de 6 GBit de um único conector SAS / SATA. Talvez isso seja um problema de configuração ou cabeamento com o backplane SAS? A configuração do backplane SAS pode ser consultada com um comando MegaRAID? Por favor informar.

Atualizar

Conforme esperado por poige e Peter, o desempenho de leitura mais lento que o esperado provavelmente é causado pelo armazenamento em cache do subsistema de E / S do Linux.

Ao usar o sinalizador direto no comando dd, recebo

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

o que é muito melhor, mas ainda 10% mais lento que a velocidade de gravação. O uso de oflag = direct não afetou a velocidade de gravação.

poige está exatamente certo sobre o cache de gravação, mas aqui estão mais detalhes.

dd com zeros e o uso de cache de gravação não é o caminho certo para fazer benchmarks (a menos que você queira testar o cache de gravação, o que provavelmente é útil apenas para um sistema de arquivos, para ver o quanto ele sincroniza metadados, cria novos arquivos etc.) ) (e provavelmente dd é sempre o tipo errado de referência, mas funciona para um teste muito básico)

Eu sugiro que você use dd com pelo menos uma das seguintes opções:

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.

E não use zero também. Algum hardware / software / firmware inteligente pode usar alguns atalhos se os dados forem tão previsíveis quanto zeros. Isto é especialmente verdade se houver compressão que suponho que você não esteja usando. Em vez disso, use um arquivo aleatório na memória (como / dev / shm). urandom é lento, então você precisa escrevê-lo em algum lugar temporariamente para lê-lo novamente. Crie um arquivo aleatório de 50 MB:

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

Leia o arquivo várias vezes para escrevê-lo (aqui eu uso o gato para lê-lo 6 vezes):

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

rm /dev/shm/randfile

Lembre-se também de que as leituras do raid1 são mais rápidas em operações paralelas, para que os discos possam ser usados ​​independentemente. Provavelmente, não é inteligente o suficiente para coordenar os discos para ler partes diferentes da mesma operação com discos diferentes.

A chave da resposta para sua pergunta é a leitura antecipada . Era uma vez, eu também tive esse problema .

IOW, para otimizar o desempenho da leitura seqüencial, todos os discos devem estar permanentemente envolvidos na entrada.

Quando você usa ddw / o directio(consulte man dd), a operação de gravação não está sendo executada imediatamente, mas passa pelo cache do SO, portanto, há mais chances de envolver todos os discos sequencialmente e obter o máximo desempenho possível.