Desempenho do Linux md vs. LVM

Estou tentando ajustar o meu NAS, executando o openfiler e me perguntando por que estou obtendo desempenho de leitura relativamente ruim de 4 unidades WD RE3 no RAID 5.

EDIT: Observe que estou falando sobre a velocidade de leitura do disco em buffer e não as velocidades em cache

EDIT: Formatação alterada para deixar claro que existem dois conjuntos de saída.

Quando executo o hdparm no dispositivo meta, obtenho os níveis de desempenho esperados, diminuo para o volume e é um terço da velocidade!

Alguém tem alguma idéia do porquê? O LVM é tão ruim assim?

reitor

Resultados Meta device / dev / md0

[root @ nas2 etc] # hdparm -tT / dev / md0
/ dev / md0:
 Tempo de leitura em cache: 4636 MB em 2,00 segundos = 2318,96 MB / s
 Tempo limite de leituras em disco buffer: 524 MB em 3,01 segundos = 174,04 MB / s

Resultados do grupo vol / dev / mapper / vg1-vol1

[root @ nas2 etc] # hdparm -tT / dev / mapper / vg1-vol1
/ dev / mapper / vg1-vol1:
 Tempo de leitura em cache: 4640 MB em 2,00 segundos = 2320,28 MB / s
 Cronometrando leituras de disco em buffer: 200 MB em 3,01 segundos = 66,43 MB / s

Edit: Veja a seção da página de manual do hdparm, que sugere que este é um teste perfeitamente válido para o desempenho de leitura sequencial, que é o problema que estou tentando resolver.

-t Execute intervalos de leituras do dispositivo para fins de comparação e benchmark. Para obter resultados significativos, esta operação deve ser repetida 2-3 vezes
              sistema inativo (sem outros processos ativos) com pelo menos alguns megabytes de memória livre. Isso exibe a velocidade da leitura através do buffer
              cache no disco sem nenhum armazenamento em cache prévio de dados. Essa medição é uma indicação de quão rápido o inversor pode suportar leituras sequenciais de dados sob
              Linux, sem qualquer sobrecarga do sistema de arquivos. Para garantir medições precisas, o cache do buffer é liberado durante o processamento de -t usando o BLKFLSBUF
              ioctl. Se o sinalizador -T também for especificado, um fator de correção baseado no resultado de -T será incorporado no resultado relatado para o -t
              Operação.

As configurações padrão do readahead para o LVM são realmente pessimistas. Experimente blockdev --setra 8192 /dev/vg1/vol1e veja o que isso aumenta seu desempenho LVM. Você sempre terá um impacto no desempenho usando o LVM; medimos em sistemas configurados adequadamente em cerca de 10% do desempenho do dispositivo de bloco subjacente.

Não tenho uma boa explicação, mas posso confirmar os resultados.

Teste de RAID (unidades RAID5, 4x1,5 TB)

root@enterprise:# hdparm -tT /dev/md2
/dev/md2:
 Timing cached reads:   2130 MB in  2.00 seconds = 1065.81 MB/sec
 Timing buffered disk reads:  358 MB in  3.00 seconds = 119.15 MB/sec
root@enterprise:# hdparm -tT /dev/md2
/dev/md2:
 Timing cached reads:   2168 MB in  2.00 seconds = 1084.54 MB/sec
 Timing buffered disk reads:  358 MB in  3.01 seconds = 119.10 MB/sec

teste de volume que usa o md2 como dispositivo físico.

root@enterprise:# hdparm -tT /dev/mapper/vg2-data
/dev/mapper/vg2-data:
 Timing cached reads:   2078 MB in  2.00 seconds = 1039.29 MB/sec
 Timing buffered disk reads:  176 MB in  3.03 seconds =  58.04 MB/sec
root@enterprise:# hdparm -tT /dev/mapper/vg2-data
/dev/mapper/vg2-data:
 Timing cached reads:   2056 MB in  2.00 seconds = 1028.06 MB/sec
 Timing buffered disk reads:  154 MB in  3.03 seconds =  50.81 MB/sec

Fiz a alteração proposta pela womble e vi resultados como este.

root@enterprise:# blockdev --setra 8192 /dev/mapper/vg2-data

root@enterprise:# hdparm -tT /dev/mapper/vg2-data
/dev/mapper/vg2-data:
 Timing cached reads:   2106 MB in  2.00 seconds = 1053.82 MB/sec
 Timing buffered disk reads:  298 MB in  3.00 seconds =  99.26 MB/sec
root@enterprise:# hdparm -tT /dev/mapper/vg2-data
/dev/mapper/vg2-data:
 Timing cached reads:   2044 MB in  2.00 seconds = 1022.25 MB/sec
 Timing buffered disk reads:  280 MB in  3.03 seconds =  92.45 MB/sec

Certifique-se de comparar maçãs com maçãs.

hdparm -t lê desde o início do dispositivo, que também é a parte mais rápida do seu disco, se você estiver oferecendo um disco inteiro (e está girando as travessas).

Certifique-se de compará-lo com um LV desde o início do disco.

Para ver o uso do mapeamento pvdisplay -m.

(certo, certo, a diferença nos números pode ser insignificante. Mas pelo menos pense nisso :)

A carga de trabalho criada pelo hdparm -T não é representativa para quase nenhum caso de uso, exceto as leituras de streaming de um único arquivo grande. Além disso, se o desempenho for uma preocupação, não use o raid5.

Você pode descobrir onde o hdparm está gastando seu tempo com blktrace (se estiver em E / S) ou oprofile (se estiver na CPU). Conhecer a configuração do LVM também ajudaria (pvdisplay, vgdisplay, lvdisplay).