leitura sequencial lenta do pool do ZFS

Question

Eu tenho uma pergunta relacionada sobre esse problema, mas ficou muito complicado e muito grande, então decidi que deveria dividir a questão em NFS e questões locais. Eu também tentei perguntar sobre isso na lista de discussão zfs-discuss sem muito sucesso.

Cópia lenta entre diretórios NFS / CIFS no mesmo servidor

Esboço: como estou configurado e o que estou esperando

1. Eu tenho um pool do ZFS com 4 discos. 2 TB RED configurado como 2 espelhos que são distribuídos (RAID 10). No Linux, zfsonlinux. Não há dispositivos de cache ou log.
2. Os dados são balanceados em espelhos (importantes para o ZFS)
3. Cada disco pode ler (raw w / dd) a 147MB / seg em paralelo, fornecendo uma taxa de transferência combinada de 588MB / seg.
4. Espero escrever cerca de 115 MB / s, ler 138 MB / s e reescrever 50 MB / s de dados sequenciais de cada disco, com base em benchmarks de um disco RED semelhante de 4 TB. Espero não menos que 100MB / s de leitura ou gravação, já que qualquer disco pode fazer isso nos dias de hoje.
5. Pensei em ver 100% de utilização de IO em todos os 4 discos quando em carga lendo ou gravando dados sequenciais. E que os discos estariam gastando mais de 100MB / s com 100% de utilização.
6. Eu pensei que o pool me daria cerca de 2x para escrever, 2x para regravar e 4x para leitura em um único disco - estou errado?
7. NOVO Achei que um zvol ext4 no mesmo pool teria aproximadamente a mesma velocidade que o ZFS

O que eu realmente obtenho

Acho que o desempenho de leitura do pool não é tão alto quanto eu esperava

bonnie ++ referência na piscina de alguns dias atrás

Version  1.97       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
igor            63G    99  99 232132  47 118787  27   336  97 257072  22  92.7   6

bonnie ++ em uma única unidade de 4 TB VERMELHA por conta própria em um zpool

Version  1.97       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
igor            63G   101  99 115288  30 49781  14   326  97 138250  13 111.6   8

De acordo com isso, as velocidades de leitura e reescrita são apropriadas com base nos resultados de um único drive VERMELHO de 4TB (eles são duplos). No entanto, a velocidade de leitura que eu esperava seria de cerca de 550MB / seg (4x a velocidade da unidade de 4TB) e eu esperaria pelo menos por volta de 400MB / seg. Em vez disso, estou vendo cerca de 260 MB / s

bonnie ++ na piscina a partir de agora, enquanto coletamos as informações abaixo. Não é o mesmo que antes, e nada mudou.

Version  1.97       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
igor            63G   103  99 207518  43 108810  24   342  98 302350  26 256.4  18

zpool iostat durante a gravação. Parece-me bem.

                                                 capacity     operations    bandwidth
pool                                          alloc   free   read  write   read  write
--------------------------------------------  -----  -----  -----  -----  -----  -----
pool2                                         1.23T  2.39T      0  1.89K  1.60K   238M
  mirror                                       631G  1.20T      0    979  1.60K   120M
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469      -      -      0   1007  1.60K   124M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX      -      -      0    975      0   120M
  mirror                                       631G  1.20T      0    953      0   117M
    ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536      -      -      0  1.01K      0   128M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE      -      -      0    953      0   117M

zpool iostat durante a reescrita. Parece ok para mim, eu acho .

                                                 capacity     operations    bandwidth
pool                                          alloc   free   read  write   read  write
--------------------------------------------  -----  -----  -----  -----  -----  -----
pool2                                         1.27T  2.35T   1015    923   125M   101M
  mirror                                       651G  1.18T    505    465  62.2M  51.8M
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469      -      -    198    438  24.4M  51.7M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX      -      -    306    384  37.8M  45.1M
  mirror                                       651G  1.18T    510    457  63.2M  49.6M
    ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536      -      -    304    371  37.8M  43.3M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE      -      -    206    423  25.5M  49.6M

Aqui é onde eu me pergunto o que está acontecendo

zpool iostat durante a leitura

                                                 capacity     operations    bandwidth
pool                                          alloc   free   read  write   read  write
--------------------------------------------  -----  -----  -----  -----  -----  -----
pool2                                         1.27T  2.35T  2.68K     32   339M   141K
  mirror                                       651G  1.18T  1.34K     20   169M  90.0K
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469      -      -    748      9  92.5M  96.8K
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX      -      -    623     10  76.8M  96.8K
  mirror                                       651G  1.18T  1.34K     11   170M  50.8K
    ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536      -      -    774      5  95.7M  56.0K
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE      -      -    599      6  74.0M  56.0K

iostat -x durante a mesma operação de leitura. Observe como% de IO não está em 100%.

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdb               0.60     0.00  661.30    6.00 83652.80    49.20   250.87     2.32    3.47    3.46    4.87   1.20  79.76
sdd               0.80     0.00  735.40    5.30 93273.20    49.20   251.98     2.60    3.51    3.51    4.15   1.20  89.04
sdf               0.50     0.00  656.70    3.80 83196.80    31.20   252.02     2.23    3.38    3.36    6.63   1.17  77.12
sda               0.70     0.00  738.30    3.30 93572.00    31.20   252.44     2.45    3.33    3.31    7.03   1.14  84.24

zpool e configurações de conjunto de dados de teste:

• atime is off
• compression is off
• ashift is 0 (autodetect - my understanding was that this was ok)
• zdb says disks are all ashift=12
• module - options zfs zvol_threads=32 zfs_arc_max=17179869184
• sync = standard

Editar - 30 de outubro de 2015

Eu fiz mais alguns testes

• dataset bonnie++ w/recordsize=1M = 226MB write, 392MB read much better
• dataset dd w/record size=1M = 260MB write, 392MB read much better
• zvol w/ext4 dd bs=1M = 128MB write, 107MB read why so slow?
• dataset 2 processess in parallel = 227MB write, 396MB read
• dd direct io makes no different on dataset and on zvol

Estou muito mais feliz com o desempenho com o aumento do tamanho do registro. Quase todos os arquivos da piscina têm mais de 1 MB. Então eu vou deixar assim. Os discos ainda não estão recebendo 100% de utilização, o que me faz pensar se ainda pode ser muito mais rápido. E agora estou me perguntando por que o desempenho do zvol é tão ruim, já que é algo que eu (levemente) uso.

Tenho o prazer de fornecer qualquer informação solicitada nos comentários / respostas. Há também toneladas de informações postadas na minha outra pergunta: Cópia lenta entre diretórios NFS / CIFS no mesmo servidor

Estou plenamente ciente de que posso simplesmente não entender algo e que isso pode não ser um problema. Agradecemos antecipadamente.

Para deixar claro, a pergunta é: Por que o pool do ZFS não é tão rápido quanto eu esperava? E talvez haja algo mais errado?

    

Answer 1

Consegui obter velocidades muito próximas dos números que eu esperava.

Eu estava procurando por 400MB / s e gerenciava 392MB / s . Então eu digo que é problema resolvido. Com a adição posterior de um dispositivo de cache, eu consegui 458MB / sec read (em cache, acredito).

1. Inicialmente, isso foi obtido simplesmente aumentando o valor recordsize do conjunto de dados do ZFS para 1M

zfs set recordsize=1M pool2/test

Acredito que essa alteração apenas resulte em menos atividade de disco, portanto, leituras e gravações síncronas mais eficientes. Exatamente o que eu estava pedindo.

Resultados após a alteração

• bonnie ++ = 226MB de gravação, 392MB de leitura
• dd = 260MB de gravação, 392MB de leitura
• 2 processos em paralelo = 227MB de gravação, 396MB de leitura

2. Eu gerenciei ainda melhor quando adicionei um dispositivo de cache (SSD de 120 GB). A gravação é um pouco mais lenta, não sei porquê.

Version  1.97       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
igor            63G           208325  48 129343  28           458513  35 326.8  16

O truque com o dispositivo de cache era definir l2arc_noprefetch=0 em /etc/modprobe.d/zfs.conf . Ele permite que o ZFS armazene em cache dados contínuos / sequenciais. Só faça isso se o seu dispositivo de cache for mais rápido que o seu array, como o meu.

Depois de se beneficiar da alteração no registro do meu conjunto de dados, achei que poderia ser uma maneira semelhante de lidar com o desempenho ruim do zvol.

Me deparei com várias pessoas mencionando que obtiveram bom desempenho usando volblocksize=64k , então tentei. Sem sorte.

zfs create -b 64k -V 120G pool/volume

Mas então eu li que o ext4 (o sistema de arquivos com o qual eu estava testando) suporta opções para RAID como stride e stripe-width , que eu nunca usei antes. Então eu usei este site para calcular as configurações necessárias: link e formatou o zvol novamente.

mkfs.ext3 -b 4096 -E stride=16,stripe-width=32 /dev/zvol/pool/volume

Corri bonnie++ para fazer um benchmark simples e os resultados foram excelentes. Eu não tenho os resultados comigo infelizmente, mas eles foram pelo menos 5-6x mais rápido para as gravações, como eu me lembro. Eu atualizarei esta resposta novamente se fizer um benchmark novamente.

    

Answer 2

Seus resultados são perfeitamente razoáveis, enquanto sua expectativa não é: você exagera a melhoria de desempenho de leitura dada pelo RAID1 (e, por extensão, pelo RAID10). O ponto é que um espelhamento bidirecional dá no máximo 2x a velocidade de leitura / IOPs do disco único, mas o desempenho do mundo real pode estar entre 1x-2x.

Vamos esclarecer com um exemplo. Imagine ter um sistema com um espelho bidirecional, com cada disco capaz de 100 MB / s (sequencial) e 200 IOPS. Com uma profundidade de fila de 1 (máximo de uma única solicitação pendente), essa matriz terá não vantagem sobre um único disco: RAID1 divide solicitações IO na fila de dois discos, mas não dividiu uma única solicitação em dois discos (pelo menos, qualquer implementação que vi se comportou dessa maneira). Por outro lado, se sua fila de E / S for maior (por exemplo: você tem 4/8 pedidos pendentes), a taxa de transferência total do disco será significativamente maior do que o disco único.

Um ponto semelhante pode ser feito para o RAID0, mas, nesse caso, o que determina as melhorias médias é uma função não apenas do tamanho da fila, mas também do tamanho da solicitação de E / S: se o tamanho médio da E / S for menor do que o tamanho do bloco, ele não será dividido em dois (ou mais) discos, mas será servido por um único. Seus resultados com o registro aumentado de Bonnie ++ mostram esse comportamento exato: a distribuição é muito beneficiada pelo maior tamanho de OI.

Agora deve ficar claro que combinar os dois níveis de RAID em uma matriz RAID10 não levará a um dimensionamento de desempenho linear, mas definirá um limite superior para ela. Tenho certeza de que, se você executar várias instâncias dd / bonnie ++ (ou usar fio para manipular diretamente a fila de I / O), terá resultados mais alinhados com sua expectativa original, simplesmente porque você sobrecarregará seu array de IO modo completo (várias solicitações de E / S aleatórias sequenciais / aleatórias), em vez de carregá-las somente de solicitações de E / S sequenciais.