Mau desempenho contínuo de gravação no RAID-5 quando não está escrevendo grandes quantidades

Question

Mau desempenho contínuo de gravação no RAID-5 quando não está escrevendo grandes quantidades

#1 resposta do (1 votos)

1

Eu tive alguns problemas para conseguir um desempenho aceitável de leitura / gravação para meu RAID5 + crypt + ext4 e finalmente consegui rastreá-lo para o seguinte problema:

Hardware

Discos rígidos 4x WD RED 3 TB WDC WD30EFRX-68EUZN0 como / dev / sd [efgh]
sde e sdf são conectados via controlador A usando um link SATA de 3 Gbps / s (embora 6 Gbps estivessem disponíveis)
sdg e sdh são conectados via controlador B usando um link SATA de 6 Gbps / s

Desempenho de disco único

Escreva o teste 4 vezes para cada disco (tudo como eu esperava)

# dd if=/dev/zero of=/dev/sd[efgh] bs=2G count=1 oflag=dsync
sde: 2147479552 bytes (2.1 GB) copied, xxx s, [127, 123, 132, 127] MB/s
sdf: 2147479552 bytes (2.1 GB) copied, xxx s, [131, 130, 118, 137] MB/s
sdg: 2147479552 bytes (2.1 GB) copied, xxx s, [145, 145, 145, 144] MB/s
sdh: 2147479552 bytes (2.1 GB) copied, xxx s, [126, 132, 132, 132] MB/s

Leia o teste usando hdparm e dd (tudo como eu esperava)

# hdparm -tT /dev/sd[efgh]
# echo 3 | tee /proc/sys/vm/drop_caches; dd of=/dev/null if=/dev/sd[efgh] bs=2G count=1 iflag=fullblock

(sde)
Timing cached reads:   xxx MB in  2.00 seconds = [13983.68, 14136.87] MB/sec
Timing buffered disk reads: xxx MB in  3.00 seconds = [143.16, 143.14] MB/sec
2147483648 bytes (2.1 GB) copied, xxx s, [140, 141] MB/s

(sdf)
Timing cached reads:   xxx MB in  2.00 seconds = [14025.80, 13995.14] MB/sec
Timing buffered disk reads: xxx MB in  3.00 seconds = [140.31, 140.61] MB/sec
2147483648 bytes (2.1 GB) copied, xxx s, [145, 141] MB/s

(sdg)
Timing cached reads:   xxx MB in  2.00 seconds = [14005.61, 13801.93] MB/sec
Timing buffered disk reads: xxx MB in  3.00 seconds = [153.11, 151.73] MB/sec
2147483648 bytes (2.1 GB) copied, xxx s, [154, 155] MB/s

(sdh)
Timing cached reads:   xxx MB in  2.00 seconds = [13816.84, 14335.93] MB/sec
Timing buffered disk reads: xxx MB in  3.00 seconds = [142.50, 142.12] MB/sec
2147483648 bytes (2.1 GB) copied, xxx s, [140, 140] MB/s

Partições em sd [efgh]

4x 32 GiB para testes

# gdisk -l /dev/sd[efgh]
GPT fdisk (gdisk) version 0.8.10

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sde: 5860533168 sectors, 2.7 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): xxx
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 5860533134
Partitions will be aligned on 2048-sector boundaries
Total free space is 5793424237 sectors (2.7 TiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048        67110911   32.0 GiB    FD00  Linux RAID

Raid array

# mdadm --create --verbose /dev/md0 --level=5 --raid-devices=4 --chunk=256K /dev/sd[efgh]1
(some tests later ...)
# mdadm --grow --verbose /dev/md0 --layout=right-asymmetric
# mdadm --detail /dev/md0
/dev/md0:
    Version : 1.2
  Creation Time : Sat Dec 10 03:07:56 2016
     Raid Level : raid5
     Array Size : 100561920 (95.90 GiB 102.98 GB)
  Used Dev Size : 33520640 (31.97 GiB 34.33 GB)
   Raid Devices : 4
  Total Devices : 4
    Persistence : Superblock is persistent

    Update Time : Sat Dec 10 23:56:53 2016
          State : clean
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : right-asymmetric
     Chunk Size : 256K

           Name : vm:0  (local to host vm)
           UUID : 80d0f886:dc380755:5387f78c:1fac60da
         Events : 158

    Number   Major   Minor   RaidDevice State
       0       8       65        0      active sync   /dev/sde1
       1       8       81        1      active sync   /dev/sdf1
       2       8       97        2      active sync   /dev/sdg1
       4       8      113        3      active sync   /dev/sdh1

Situação atual

Eu esperava que o array executasse aproximadamente entre 350 - 400 MB / s para leituras e gravações contínuas. Ler ou escrever todo o volume produz resultados perfeitamente dentro desse intervalo:

# echo 3 | tee /proc/sys/vm/drop_caches; dd of=/dev/null if=/dev/md0 bs=256K
102975406080 bytes (103 GB) copied, 261.373 s, 394 MB/s

# dd if=/dev/zero of=/dev/md0 bs=256K conv=fdatasync
102975406080 bytes (103 GB) copied, 275.562 s, 374 MB/s

No entanto, o desempenho de gravação depende muito da quantidade de dados gravados. Como esperado, a taxa de transferência aumenta com a quantidade de dados, mas cai quando chega a 2 GiB e só se recupera lentamente quando aumenta ainda mais o tamanho:

# dd if=/dev/zero of=/dev/md0 bs=256K conv=fdatasync count=x
count=1: 262144 bytes (262 kB) copied, xxx s, [3.6, 7.6, 8.9, 8.9] MB/s
count=2: 524288 bytes (524 kB) copied, xxx s, [3.1, 17.7, 15.3, 15.7] MB/s
count=4: 1048576 bytes (1.0 MB) copied, xxx s, [13.2, 23.9, 26.9, 25.4] MB/s
count=8: 2097152 bytes (2.1 MB) copied, xxx s, [24.3, 46.7, 45.9, 42.8] MB/s
count=16: 4194304 bytes (4.2 MB) copied, xxx s, [5.1, 77.3, 42.6, 73.2, 79.8] MB/s
count=32: 8388608 bytes (8.4 MB) copied, xxx s, [68.6, 101, 99.7, 101] MB/s
count=64: 16777216 bytes (17 MB) copied, xxx s, [52.5, 136, 159, 159] MB/s
count=128: 33554432 bytes (34 MB) copied, xxx s, [38.5, 175, 185, 189, 176] MB/s
count=256: 67108864 bytes (67 MB) copied, xxx s, [53.5, 244, 229, 238] MB/s
count=512: 134217728 bytes (134 MB) copied, xxx s, [111, 288, 292, 288] MB/s
count=1K: 268435456 bytes (268 MB) copied, xxx s, [171, 328, 319, 322] MB/s
count=2K: 536870912 bytes (537 MB) copied, xxx s, [228, 337, 330, 334] MB/s
count=4K: 1073741824 bytes (1.1 GB) copied, xxx s, [338, 348, 348, 343] MB/s <-- ok!
count=8K: 2147483648 bytes (2.1 GB) copied, xxx s, [168, 147, 138, 139] MB/s <-- bad!
count=16K: 4294967296 bytes (4.3 GB) copied, xxx s, [155, 160, 178, 144] MB/s
count=32K: 8589934592 bytes (8.6 GB) copied, xxx s, [256, 238, 264, 246] MB/s
count=64K: 17179869184 bytes (17 GB) copied, xxx s, [298, 285] MB/s
count=128K: 34359738368 bytes (34 GB) copied, xxx s, [347, 336] MB/s
count=256K: 68719476736 bytes (69 GB) copied, xxx s, [363, 356] MB/s <-- getting better

(abaixo de 2 GiB a primeira medição parece indicar o uso de algum cache de leitura)

Ao transferir 2 GiB ou mais do que observei algo estranho em iotop :

Fase 1: no começo "Total DISK WRITE" e "Actual DISK WRITE" são ambos sobre "400 MB / s". dd tem um valor de OI em torno de 85%, enquanto todos os outros estão em 0%. Esta fase dura mais tempo em transferências maiores.
Fase 2: Alguns segundos (~ 16 s) antes da transmissão ser concluída, um kworker salta e / rouba / 30 - 50 pontos percentuais de IO de dd . A distribuição flutua entre 30:50% e 50:30%. Ao mesmo tempo, o "Total DISK WRITE" cai para 0 B / se "ACTUAL DISK WRITE" pula entre 20 - 70 MB / s. Esta fase parece durar por um tempo constante.
Fase 3: Nos últimos 3 segundos, a mensagem "DISCO REAL real" aumenta para > 400 MB / s enquanto "Total DISK WRITE" permanece em 0 B / s. dd e kworker estão listados com um valor de IO de 0%
Fase 4: o valor de E / S de dd pula até 5% por um único segundo. Ao mesmo tempo, a transferência é concluída.

Mais alguns testes

# dd if=/dev/zero of=/dev/md0 bs=256K count=32K oflag=direct
8589934592 bytes (8.6 GB) copied, 173.083 s, 49.6 MB/s

# dd if=/dev/zero of=/dev/md0 bs=256M count=64 oflag=direct
17179869184 bytes (17 GB) copied, 47.792 s, 359 MB/s

# dd if=/dev/zero of=/dev/md0 bs=768M count=16K oflag=direct
50734301184 bytes (51 GB) copied, 136.347 s, 372 MB/s <-- peak performance

# dd if=/dev/zero of=/dev/md0 bs=1G count=16K oflag=direct
41875931136 bytes (42 GB) copied, 112.518 s, 372 MB/s <-- peak performance

# dd if=/dev/zero of=/dev/md0 bs=2G count=16 oflag=direct
34359672832 bytes (34 GB) copied, 103.355 s, 332 MB/s

# dd if=/dev/zero of=/dev/md0 bs=256K count=32K oflag=dsync
8589934592 bytes (8.6 GB) copied, 498.77 s, 17.2 MB/s

# dd if=/dev/zero of=/dev/md0 bs=256M count=64 oflag=dsync
17179869184 bytes (17 GB) copied, 58.384 s, 294 MB/s

# dd if=/dev/zero of=/dev/md0 bs=1G count=8 oflag=dsync
8589934592 bytes (8.6 GB) copied, 26.4799 s, 324 MB/s

# dd if=/dev/zero of=/dev/md0 bs=2G count=8 oflag=dsync
17179836416 bytes (17 GB) copied, 192.327 s, 89.3 MB/s

# dd if=/dev/zero of=/dev/md0 bs=256K; echo "sync"; sync
102975406080 bytes (103 GB) copied, 275.378 s, 374 MB/s
sync

bs=256K oflag=direct - > 100% IO, sem kworker presente, mau desempenho
bs=1G oflag=direct - > < 5% de E / S, não kworker presente, ok desempenho
bs=2G oflag=direct - > > 80% IO, kworker salta de vez em quando, ok desempenho
oflag=dsync - > < 5% IO, kworker pula de vez em quando; precisa de tamanhos de blocos enormes para obter velocidade aceitável, mas > 2G resulta em uma queda de desempenho massiva.
echo "sync"; sync - > o mesmo que conv=fdatasync ; sync retorna imediatamente

Perguntas

Qual é a misteriosa Fase 2 em que ambos os processos parecem lutar por IO?

Quem está transferindo os dados para o hardware na fase 3?

E o mais importante: como posso minimizar o efeito estranho para obter os 400 MB / s completos que o array parece ser capaz de fornecer? (Ou até estou perguntando um problema XY?)

Bônus

Há uma longa história de tentativa e erro antes do estado atual. Troquei o agendador de cfq para noop e diminuí o tamanho do bloco de RAIDs de 512k para 256k, gerando resultados ligeiramente melhores. Mudar para --layout=right-asymmetric não mudou nada. A desativação temporária do cache de gravação do disco rígido teve pior desempenho.

A camada de cripta mencionada na primeira sentença está atualmente completamente ausente e será reintroduzida posteriormente.

# uname -a
Linux vm 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux

performance cache debian raid mdadm

por Kai Giebeler 11.12.2016 / 02:18

1 resposta

Tags performance cache debian raid mdadm

Posso remover o linux-image-3.2.0-4-686-pae? Sintaxe correta para um registro SPF

score 1 · Accepted Answer

O que você está vendo é um artefato de sua linha de comando dd , especificamente da opção conv=fdatasync . Na página de manual :

Each CONV symbol may be:
...
fdatasync: physically write output file data before finishing
...

conv=fdatasync basicamente instrui dd a executar um único syscall fdatasync final antes de fazer a devolução. No entanto, write é armazenado em cache enquanto o dd é executado. Suas fases de E / S podem ser explicadas da seguinte forma:

dd escreve rapidamente no pagecache, sem realmente tocar no disco
o pagecache está quase cheio e um kernel kworker começa a liberar o disco. Durante a liberação do pagecache, dd é brevemente pausado (resultando em alta iowait ); depois que algum pagecache for liberado, dd poderá recuperar a operação
a diferença entre as gravações de disco TOTAL e ACTUAL em iotop depende de como a pagecache é, respectivamente, preenchida e liberada
o ciclo continua

Em suma, não há problema aqui. Se você quiser observar o comportamento não armazenado em cache, substitua conv=fdatasync por oflag=direct : com esse sinalizador, você pode ignorar completamente o pagecache.

Para observar o comportamento de cache, mas sincronizado, substitua conv=fdatasync por oflag=sync : com esse sinalizador, dd chama fdatasync conforme cada bloco é gravado no disco.

É possível obter mais otimização ajustando sua pilha de E / S (isto é: programador de E / S, comportamento de mesclagem, cache de distribuição, ecc), mas essa é uma outra pergunta.