Mau desempenho com o software Linux raid-10

Question

Eu tenho uma máquina com um chip controlador SAS de 8 canais LSI SAS3008, e teste de unidade individual mostra que posso gravar em qualquer disco ou todos os discos entre 174 MB / seg e 193 MB / seg com uma velocidade de gravação sustentada:

Esta é a saída do comando dd if=/dev/zero of=/dev/mapper/mpath?p1 bs=1G count=100 oflag=direct executado em paralelo para todos os 12 discos:

107374182400 bytes (107 GB) copied, 556.306 s, 193 MB/s
107374182400 bytes (107 GB) copied, 566.816 s, 189 MB/s
107374182400 bytes (107 GB) copied, 568.681 s, 189 MB/s
107374182400 bytes (107 GB) copied, 578.327 s, 186 MB/s
107374182400 bytes (107 GB) copied, 586.444 s, 183 MB/s
107374182400 bytes (107 GB) copied, 590.193 s, 182 MB/s
107374182400 bytes (107 GB) copied, 592.721 s, 181 MB/s
107374182400 bytes (107 GB) copied, 598.646 s, 179 MB/s
107374182400 bytes (107 GB) copied, 602.277 s, 178 MB/s
107374182400 bytes (107 GB) copied, 604.951 s, 177 MB/s
107374182400 bytes (107 GB) copied, 605.44 s, 177 MB/s

No entanto, quando eu coloco esses discos juntos como um dispositivo de invasão de software 10, obtenho cerca de 500 MB / seg de velocidade de gravação. Eu esperava obter o dobro disso, já que não há penalidade para acessar esses discos ao mesmo tempo.

Eu notei o processo md10_raid10, que eu presumo que o ataque de software em si está se aproximando de 80%, e um núcleo está sempre com tempo de espera de 100% e 0% inativo. Qual núcleo é alterado, no entanto.

Além disso, o desempenho cai ainda mais quando o cache de buffer é usado para gravar no sistema de arquivos EXT4 montado, em vez de usar oflag = direct para ignorar o cache. Os discos relatam 25% de ocupação (de acordo com o monitoramento munin), mas os discos claramente não estão funcionando bem, mas eu me preocupo com o próprio dispositivo md10.

Alguma sugestão sobre onde ir em seguida? Eu estou tentando um hardware raid 10 config para comparar, embora eu possa apenas construir uma unidade de 10 discos parece - dito, espero obter 900 MB / seg escreve sustentada. Eu atualizarei esta questão quando descobrir mais.

Editar 1:

Se eu usar colocar um comando dd em um loop restrito gravando em uma partição ext4 montada nesse dispositivo, e não usar o cache de buffer (oflag = direct), posso obter mais de 950 MB / seg no pico e 855 MB / seg sustentados com algumas alterações nas bandeiras de montagem.

Se eu também ler com iflag = direct no mesmo tim, posso obter gravações de 480 MB / s e ler agora 750 MB / s.

Se eu escrever sem oflag = direct, usando assim o cache de buffer, recebo gravações de 230 MB / seg e leituras de 1.2 MB / seg, mas a máquina parece ser muito lenta.

Então, a questão é: por que usar o cache de buffer afetaria seriamente o desempenho? Eu tentei várias estratégias de enfileiramento de disco incluindo o uso de 'noop' no nível da unidade e colocando 'deadline' ou 'cfq' no dispositivo multi path dm apropriado, ou prazo final em todos ou nenhum no dm e prazo na unidade de backup. Parece que a unidade de suporte não deve ter nenhum, e o dispositivo multi-caminho deve ser o que eu quero, mas isso não afeta o desempenho, pelo menos no caso do cache de buffer.

    

Answer 1

Editar:

Suas observações de dd oflag=direct podem estar relacionadas a problemas de gerenciamento de energia. Use PowerTOP para ver se os estados C da sua CPU estão comutados com muita frequência acima de C1 sob carga de gravação. Se estiverem, tente ajustar a MP para garantir que a CPU não irá dormir e re-executar os benchmarks. Consulte a documentação da sua distro sobre como fazer isso - na maioria dos casos, esse será o parâmetro% boot_de_kernel bootline, mas YMMV.

A grande diferença no desempenho entre uma gravação intel_idle.max_cstate=0 e uma gravação em buffer pode ser devido a:

• ao usar O_DIRECT, a CPU não é enviada para C3 + sleep ou
• a CPU é enviada para o C3 +, mas não importa muito devido ao processamento simplificado quando se usa O_DIRECT - apenas apontando para uma área de memória zerada e emitindo um pedido de escrita DMA precisa de menos ciclos do que o processamento em buffer e será menos sensível à latência

resposta obsoleta:

Isso se parece muito com um gargalo causado pelo único thread em O_DIRECT .

Raciocínio

• a folha de dados do controlador está prometendo uma taxa de transferência de 6.000
• sua execução md em paralelo está exibindo 170MB _{/ s} + por unidade, portanto, o caminho não é restrito pela largura de banda PCIe de conexão
• você está vendo taxas de utilização altas e próximas de 100% para md10_raid10

Embora os patches para cálculo de soma de verificação RAID5 multithread tenham sido confirmados para dd em 2013, não consigo encontrar nada sobre aprimoramentos RAID1 / RAID10 semelhantes, então eles podem simplesmente não estar lá.

Coisas para experimentar

• mais do que um único tópico de escrita com mdraid , apenas para ver se muda alguma coisa
• uma implementação RAID10 diferente - LVM RAID 10 vem à mente, mas você também pode olhe para o ZFS ¹ que foi projetado exatamente com este caso de uso (muitos discos, sem controladores RAID de hardware) em mente
• possivelmente uma versão mais recente do Kernel

FWIW, você raramente (ou nunca) verá o pico de desempenho de gravação (especialmente com um sistema de arquivos não-CoW) na largura de banda com a mídia de armazenamento mecânico. Na maioria das vezes, você será restringido pelos tempos de busca, portanto, o pico de largura de banda não deve ser uma grande preocupação, desde que atenda aos seus requisitos mínimos.

¹ se você fizer ZFS, você deve refinar seu método de teste, pois a gravação de blocos de todos os zero em um conjunto de dados ZFS pode ser arbitrariamente rápida. Zeros não são gravados em discos, mas apenas vinculados ao bloco all-zero, se a compactação estiver ativada para o conjunto de dados.