2 unidades, software lento RAID1 (md)

Question

Eu tenho um servidor da hetzner.de (EQ4) com unidades 2 * SAMSUNG HD753LJ (cache de 750G 32MB).

OS é o CentOS 5 (x86_64). Unidades são combinadas em duas partições RAID1:

1. / dev / md0 que é 512 MB grande e tem apenas partições / boot
2. / dev / md1 que tem mais de 700 GB e é um grande LVM que hospeda outras partições

Agora, tenho feito alguns benchmarks e parece que, mesmo com as mesmas unidades, a velocidade difere um pouco em cada uma delas.

# hdparm -tT /dev/sda

/dev/sda:  Timing cached reads:   25612 MB in  1.99 seconds = 12860.70 MB/sec  Timing buffered disk reads:  352 MB in  3.01 seconds = 116.80 MB/sec
# hdparm -tT /dev/sdb

/dev/sdb:  Timing cached reads:   25524 MB in  1.99 seconds = 12815.99 MB/sec  Timing buffered disk reads:  342 MB in  3.01 seconds = 113.64 MB/sec

Além disso, quando eu corro, por exemplo. pgbench que está estressando IO bastante, eu posso ver o seguinte da saída iostat:

Device:         rrqm/s   wrqm/s   r/s   w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00   231.40  0.00 298.00     0.00  9683.20    32.49     0.17    0.58   0.34  10.24
sda1              0.00     0.00  0.00   0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda2              0.00   231.40  0.00 298.00     0.00  9683.20    32.49     0.17    0.58   0.34  10.24
sdb               0.00   231.40  0.00 301.80     0.00  9740.80    32.28    14.19   51.17   3.10  93.68
sdb1              0.00     0.00  0.00   0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdb2              0.00   231.40  0.00 301.80     0.00  9740.80    32.28    14.19   51.17   3.10  93.68
md1               0.00     0.00  0.00 529.60     0.00  9692.80    18.30     0.00    0.00   0.00   0.00
md0               0.00     0.00  0.00   0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
dm-0              0.00     0.00  0.00   0.60     0.00     4.80     8.00     0.00    0.00   0.00   0.00
dm-1              0.00     0.00  0.00 529.00     0.00  9688.00    18.31    24.51   49.91   1.81  95.92

Device:         rrqm/s   wrqm/s   r/s   w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00   152.40  0.00 330.60     0.00  5176.00    15.66     0.19    0.57   0.19   6.24
sda1              0.00     0.00  0.00   0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda2              0.00   152.40  0.00 330.60     0.00  5176.00    15.66     0.19    0.57   0.19   6.24
sdb               0.00   152.40  0.00 326.20     0.00  5118.40    15.69    19.96   55.36   3.01  98.16
sdb1              0.00     0.00  0.00   0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdb2              0.00   152.40  0.00 326.20     0.00  5118.40    15.69    19.96   55.36   3.01  98.16
md1               0.00     0.00  0.00 482.80     0.00  5166.40    10.70     0.00    0.00   0.00   0.00
md0               0.00     0.00  0.00   0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
dm-0              0.00     0.00  0.00   0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
dm-1              0.00     0.00  0.00 482.80     0.00  5166.40    10.70    30.19   56.92   2.05  99.04

Device:         rrqm/s   wrqm/s   r/s   w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00   181.64  0.00 324.55     0.00  5445.11    16.78     0.15    0.45   0.21   6.87
sda1              0.00     0.00  0.00   0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sda2              0.00   181.64  0.00 324.55     0.00  5445.11    16.78     0.15    0.45   0.21   6.87
sdb               0.00   181.84  0.00 328.54     0.00  5493.01    16.72    18.34   61.57   3.01  99.00
sdb1              0.00     0.00  0.00   0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdb2              0.00   181.84  0.00 328.54     0.00  5493.01    16.72    18.34   61.57   3.01  99.00
md1               0.00     0.00  0.00 506.39     0.00  5477.05    10.82     0.00    0.00   0.00   0.00
md0               0.00     0.00  0.00   0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
dm-0              0.00     0.00  0.00   0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
dm-1              0.00     0.00  0.00 506.39     0.00  5477.05    10.82    28.77   62.15   1.96  99.00

E isso está me deixando completamente confuso. Como é que duas das mesmas unidades especificadas têm essa diferença na velocidade de gravação (veja util%)? Eu realmente não prestei atenção àquelas velocidades antes, então talvez essa coisa normal - se alguém pudesse confirmar eu ficaria muito grato.

Caso contrário, se alguém tiver visto esse comportamento novamente ou souber o que está causando tal comportamento, eu realmente apreciaria a resposta.

Eu também adicionarei que as saídas "smartctl -a" e "hdparm -I" são exatamente as mesmas e não estão indicando problemas de hardware. A unidade mais lenta foi alterada duas vezes (para novas). Também pedi para trocar as unidades por locais, e então sda eram mais lentas e sdb mais rápidas (então a lenta era a mesma). Os cabos SATA foram trocados duas vezes já.

    

Answer 1

Poderia, por favor, experimentar a ferramenta bonnie++ benchmark? Você deve executá-lo com o dobro do tamanho da memória (por exemplo, 1 GB):

bonnie++ -s $((2*1024))

A descrição do seu problema me faz pensar que é o controlador que não pode manipular facilmente as gravações paralelas que o software RAID1 faz. Use o comando acima nas seguintes situações. Para verificar se esta hipótese é verdadeira, por favor faça:

1) Benchmarks separados para cada disco rígido. Hipótese diz que os resultados serão similares.

2) Compare o RAID1.

3) Benchmark simultâneo em diferentes discos. A hipótese diz que deveria parecer mais 2) que 1).

Boa sorte,
João Miguel Neves

    

Answer 2

Concordo que você está obtendo uma disparidade de desempenho entre os discos: basta observar a disparidade no tamanho das filas. No entanto, ainda não sabemos se devemos culpar os discos ou algo mais alto na pilha. Algumas experiências:

1. Crie um md3 com uma partição do sdb como o primeiro elemento do espelho e uma partição do sda como o segundo: veja se o desempenho segue o disco ou o software RAID. (Isso me surpreenderia, mas pode valer a pena ser feito antes do segundo experimento que requer acesso (eugh) físico).

2. Troque fisicamente as conexões para sda e sdb. Se o desempenho mudar agora, você deve culpar seu controlador de disco.

Answer 3

Eu acho que seus dados são normais, eles são diferentes, mas apenas por muito poucos%. Eu já vi esse tipo de valor em muitos outros drives iguais.

Andrea

    

Answer 4

Desculpe, eu cruzei meus olhos no final das linhas e também não ignorei o que você escreveu sobre as diferenças sobre% util das duas unidades.

Não, não é normal e depois do que você disse, acho que provavelmente o problema é o controlador. Os dois canais estão configurados da mesma maneira?

    

Answer 5

Eu suspeitaria do ataque como parte dessa observação. As unidades parecem mostrar w / se wsec / s quase idênticos. Como o md raid replica a gravação em dois drives conectados ao mesmo controlador, é possível que a transferência dos dados pelo barramento aconteça apenas uma vez, assim, um drive pode chegar ao topo em termos de utilização de cpu enquanto o outro apenas transfere o bloco já presente do controlador. você tentou reproduzir o comportamento sem um ataque md?

    

Answer 6

Pode ser por causa do bitmap de intenção de gravação? Causa lentidão do RAID-1.

Desativar o bitmap com intenção de gravação aumentará a velocidade de gravação no RADI-1, mas também aumentará o tempo para a reconstrução do array em caso de falha.

    

Answer 7

Eu trabalho em uma instalação de hospedagem, e eu já vi problemas semelhantes no passado com grande unidade% util em taxas de dados que não devem maximizar a unidade. Normalmente, quando vemos que trocamos a unidade por outra e a RMA a unidade antiga.

Entre em contato com seu provedor de hospedagem e informe a eles que você está tendo esse problema, e veja se eles podem trocá-lo por outra unidade para ver se isso resolve o problema. Caso contrário, pode ser um problema no controlador de unidade.

    

Answer 8

qual escalonador de elevador você está usando? Com base em sua carga de trabalho, você pode tentar o prazo final em relação ao CFQ. Dependendo do kernel, é possível que ele tenha sido enviado com o Agendador de Antecipação ativado, que eu encontrei para ter problemas com conjuntos de md construídos.

    

Answer 9

Pode ser um problema iostat ou um problema estatístico interno do kernel. Os números do hdparm parecem ser um pouco altos, uma revisão encontrada este hd para ter uma velocidade de até 88mb / s para gravação. Também pode ser um NCQ desligado, verifique a saída do dmesg.

O teste real é para assustar os hds e executar os mesmos benchmarks, como o bonnie ++, em cada um deles.