Linux software RAID6: reconstrução lenta

Question

Estou tentando encontrar o gargalo na reconstrução de um software raid6.

## Pause rebuilding when measuring raw I/O performance
# echo 1 > /proc/sys/dev/raid/speed_limit_min
# echo 1 > /proc/sys/dev/raid/speed_limit_max
## Drop caches so that does not interfere with measuring
# sync ; echo 3 | tee /proc/sys/vm/drop_caches >/dev/null
# time parallel -j0 "dd if=/dev/{} bs=256k count=4000 | cat >/dev/null" ::: sdbd sdbc sdbf sdbm sdbl sdbk sdbe sdbj sdbh sdbg 
4000+0 records in
4000+0 records out
1048576000 bytes (1.0 GB) copied, 7.30336 s, 144 MB/s
[... similar for each disk ...]
# time parallel -j0 "dd if=/dev/{} skip=15000000 bs=256k count=4000 | cat >/dev/null" ::: sdbd sdbc sdbf sdbm sdbl sdbk sdbe sdbj sdbh sdbg 
4000+0 records in
4000+0 records out
1048576000 bytes (1.0 GB) copied, 12.7991 s, 81.9 MB/s
[... similar for each disk ...]

Assim, podemos ler sequencialmente a 140 MB / s nas faixas externas e 82 MB / s nas faixas internas em todas as unidades simultaneamente. O desempenho de gravação sequencial é semelhante.

Isso me levaria a esperar uma velocidade de recriação de 82 MB / s ou mais.

# echo 800000 > /proc/sys/dev/raid/speed_limit_min
# echo 800000 > /proc/sys/dev/raid/speed_limit_max
# cat /proc/mdstat
md2 : active raid6 sdbd[10](S) sdbc[9] sdbf[0] sdbm[8] sdbl[7] sdbk[6] sdbe[11] sdbj[4] sdbi[3](F) sdbh[2] sdbg[1]
      27349121408 blocks super 1.2 level 6, 128k chunk, algorithm 2 [9/8] [UUU_UUUUU]
      [=========>...........]  recovery = 47.3% (1849905884/3907017344) finish=855.9min speed=40054K/sec

Mas nós só temos 40 MB / s. E muitas vezes isso cai para 30 MB / s.

# iostat -dkx 1
sdbc              0.00  8023.00    0.00  329.00     0.00 33408.00   203.09     0.70    2.12   1.06  34.80
sdbd              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00
sdbe             13.00     0.00 8334.00    0.00 33388.00     0.00     8.01     0.65    0.08   0.06  47.20
sdbf              0.00     0.00 8348.00    0.00 33388.00     0.00     8.00     0.58    0.07   0.06  48.00
sdbg             16.00     0.00 8331.00    0.00 33388.00     0.00     8.02     0.71    0.09   0.06  48.80
sdbh            961.00     0.00 8314.00    0.00 37100.00     0.00     8.92     0.93    0.11   0.07  54.80
sdbj             70.00     0.00 8276.00    0.00 33384.00     0.00     8.07     0.78    0.10   0.06  48.40
sdbk            124.00     0.00 8221.00    0.00 33380.00     0.00     8.12     0.88    0.11   0.06  47.20
sdbl             83.00     0.00 8262.00    0.00 33380.00     0.00     8.08     0.96    0.12   0.06  47.60
sdbm              0.00     0.00 8344.00    0.00 33376.00     0.00     8.00     0.56    0.07   0.06  47.60

iostat diz que os discos não estão 100% ocupados (mas apenas 40-50%). Isso se encaixa com a hipótese de que o máximo é de cerca de 80 MB / s.

Como isso é invasão de software, o fator limitante pode ser a CPU. top diz:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                              
38520 root      20   0     0    0    0 R   64  0.0   2947:50 md2_raid6
 6117 root      20   0     0    0    0 D   53  0.0 473:25.96 md2_resync

Portanto, md2_raid6 e md2_resync estão claramente ocupados ocupando 64% e 53% da CPU, respectivamente, mas não próximo a 100%.

O tamanho do fragmento (128k) do RAID foi escolhido depois de medir qual tamanho menor da CPU deu a penalidade.

Se esta velocidade é normal: Qual é o fator limitante? Posso medir isso?

Se esta velocidade não estiver normal: Como posso encontrar o fator limitante? Posso mudar isso?

    

Answer 1

Não me lembro exatamente das velocidades que tive quando migrei para 6 discos RAID 6 de 4 discos RAID 5, mas eles eram semelhantes (4TB de array utilizável, 24h de reconstrução, portanto, cerca de 45MB / s).

Você precisa lembrar que mesmo o speed_limit_min dará alguma prioridade aos aplicativos que tentarem usar o array. Assim, o mecanismo usado para detectar atividades pode exigir uma carga de 50% nos discos para detectá-lo e ainda ter a capacidade de atender às solicitações de E / S. Você tentou desmontar a partição?

Para verificar se há afunilamentos, você terá que rastrear o kernel (por exemplo, usando o Linux Tracing Toolkit lttng ou System Tap). Não é fácil e vai demorar muito tempo, a menos que você tenha que reconstruir os arrays em alguns computadores. Provavelmente não vale a pena. Quanto a alterá-lo: Tenho certeza de que tais correções para o kernel Linux serão bem-vindas:)

    

Answer 2

Eu não esperaria que uma operação de recuperação Raid6 fosse de natureza seqüencial, já que ela geralmente precisa recuperar somas de verificação e blocos de dados de unidades n-1 que estão embutidas entre blocos de dados nessas unidades.

Além disso, eu esperaria uma operação um tanto sequencial (= não completa paralela) como:

1. leia o datablock1
2. leia o bloco de dados2 ...
3. leia o datablockn-1
4. leia o checksum1
5. calcula o datablockn
6. escreve o datablockn

pelo menos 5. é um ponto de sincronização, portanto a duração (1..4) é pelo menos a duração (mais lenta (1..4)). Quão bem ele é determinado pelo nível de paralelização de qualquer camada envolvida (md, driver, controller (ncq etc)).

Eu nunca esperaria uma taxa de reconstrução de um RAID6 em qualquer lugar perto dos tempos sequenciais de leitura / gravação dos discos individuais.

Para comparação: nossos arrays Equallogic do PS6000 (16x1TB) demoram cerca de 32 horas sob carga moderada para reconstruir um disco com falha.