Leitura sequencial lenta do conjunto ZFS

Eu tenho uma pergunta relacionada a esse problema, mas ele ficou muito complicado e muito grande, então decidi que deveria dividir o problema em NFS e em problemas locais. Eu também tentei perguntar sobre isso na lista de discussão do 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 ZFS com 4 discos. 2TB RED configurado como 2 espelhos listrados (RAID 10). No Linux, zfsonlinux. Não há dispositivos de cache ou log.
2. Os dados são balanceados entre espelhos (importante para o ZFS)
3. Cada disco pode ler (em bruto / dd) a 147 MB ​​/ s em paralelo, proporcionando um rendimento combinado de 588 MB / s.
4. Espero cerca de 115 MB / s de gravação, 138 MB / s de leitura e 50 MB / s de regravação de dados seqüenciais de cada disco, com base nos benchmarks de um disco RED de 4 TB semelhante. Espero não menos do que 100 MB / s de leitura ou gravação, já que qualquer disco pode fazer isso atualmente.
5. Eu pensei em ver 100% de utilização de E / S em todos os 4 discos quando estiver carregando leitura ou gravação de dados sequenciais. E que os discos estariam lançando mais de 100 MB / s com 100% de utilização.
6. Eu pensei que o pool me daria cerca de 2x gravação, 2x reescrita e 4x desempenho de leitura em um único disco - estou errado?
7. NOVO: Eu pensei que um zvol ext4 no mesmo pool teria a mesma velocidade do ZFS

O que eu realmente recebo

Acho que o desempenho de leitura da piscina não é tão alto quanto eu esperava

benchmark bonnie ++ na piscina de alguns dias atrás

Versão 1.97 ------ Saída sequencial ------ - Entrada equivalente - - Random-
Simultaneidade 1 -Por Chr- --Bloco-- -Renrite- -Por Chr- --Block-- --Seeks--
Tamanho da máquina K / seg% CP K / seg% CP K / seg% CP K / seg% CP K / seg% CP / seg% CP
igor 63G 99 99 232132 47 118787 27 336 97 257072 22 92,7 6

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

Versão 1.97 ------ Saída sequencial ------ - Entrada equivalente - - Random-
Simultaneidade 1 -Por Chr- --Bloco-- -Renrite- -Por Chr- --Block-- --Seeks--
Tamanho da máquina K / seg% CP K / seg% CP K / seg% CP K / seg% CP K / seg% CP / seg% 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 RED de 4 TB (são duplos). No entanto, a velocidade de leitura que eu esperava seria de cerca de 550 MB / s (4x a velocidade da unidade de 4 TB) e eu esperaria pelo menos cerca de 400 MB / s. Em vez disso, estou vendo em torno de 260MB / s

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

Versão 1.97 ------ Saída sequencial ------ - Entrada equivalente - - Random-
Simultaneidade 1 -Por Chr- --Bloco-- -Renrite- -Por Chr- --Block-- --Seeks--
Tamanho da máquina K / seg% CP K / seg% CP K / seg% CP K / seg% CP K / seg% CP / seg% CP
igor 63G 103 99 207518 43 108810 24 342 98 302350 26 256,4 18

iostat do zpool durante a gravação. Parece bom para mim.

                                                 largura de banda das operações de capacidade
pool alocar leitura livre gravação leitura gravação
-------------------------------------------- ----- - ---- ----- ----- ----- -----
pool2 1.23T 2.39T 0 1.89K 1.60K 238M
  espelho 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
  espelho 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

iostat do zpool durante a reescrita. Parece-me bem, eu acho .

                                                 largura de banda das operações de capacidade
pool alocar leitura livre gravação leitura gravação
-------------------------------------------- ----- - ---- ----- ----- ----- -----
pool2 1,27T 2,35T 1015923 125M 101M
  espelho 651G 1.18T 505465 62.2M 51.8M
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469 - - 198 438 24,4M 51,7M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX - - 306384 37,8M 45,1M
  espelho 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 que me pergunto o que está acontecendo

iostat do zpool durante a leitura

                                                 largura de banda das operações de capacidade
pool alocar leitura livre gravação leitura gravação
-------------------------------------------- ----- - ---- ----- ----- ----- -----
pool2 1.27T 2.35T 2.68K 32 339M 141K
  espelho 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
  espelho 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 o IO% não está em 100%.

Dispositivo: rrqm / s wrqm / sr / sw / s rkB / s wkB / s avgrq-sz avgqu-sz aguardam 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
dp 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 está desligado
• compressão está desativada
• ashift é 0 (autodetect - meu entendimento era que isso estava ok)
• zdb diz que os discos são todos ashift = 12
• módulo - opções zfs zvol_threads = 32 zfs_arc_max = 17179869184
• sincronização = padrão

Editar - 30 de outubro de 2015

Eu fiz mais alguns testes

• conjunto de dados bonnie ++ w / recordsize = 1M = 226MB de gravação, 392MB de leitura muito melhor
• conjunto de dados dd com tamanho de registro = 1M = 260MB de gravação, 392MB de leitura muito melhor
• zvol w / ext4 dd bs = 1M = 128MB de gravação, 107MB de leitura por que tão lento?
• conjunto de dados 2 processess em paralelo = 227MB de gravação, 396MB de leitura
• O dd direct io não difere no conjunto de dados e no zvol

Estou muito mais feliz com o desempenho com o aumento do tamanho do registro. Quase todos os arquivos no pool têm mais de 1 MB. Então eu vou deixar assim. Os discos ainda não estão obtendo 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, pois isso é algo que eu (levianamente) uso.

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

Estou perfeitamente ciente de que posso simplesmente não entender algo e que isso pode não ser um problema. Desde já, obrigado.

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?

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

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

1. Isso no início foi alcançado simplesmente aumentando o recordsizevalor do conjunto de dados do ZFS para1M

zfs set recordsize=1M pool2/test

Acredito que essa alteração resulta apenas em menos atividade do disco, portanto, grandes 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 = 260 MB de gravação, 392 MB de leitura
• 2 processos em paralelo = 227MB de gravação, 396MB de leitura

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

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 foi a criação l2arc_noprefetch=0em /etc/modprobe.d/zfs.conf . Ele permite que o ZFS armazene em cache dados sequenciais / de streaming. Faça isso apenas se o seu dispositivo de cache for mais rápido que o seu array, como o meu.

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

Me deparei com várias pessoas mencionando que obtiveram um bom desempenho usando um 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 que eu estava testando) suporta opções para RAID como stridee stripe-width, que eu nunca usei antes. Então, usei este site para calcular as configurações necessárias: https://busybox.net/~aldot/mkfs_stride.html e formatado 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. Infelizmente, não tenho os resultados comigo, mas eles foram pelo menos 5-6x mais rápidos para gravações, pelo que me lembro. Atualizarei esta resposta novamente se fizer um benchmark novamente.

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

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

Um ponto semelhante pode ser feito para o RAID0, mas, neste 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 que o tamanho do pedaço, ele não será distribuído em dois (ou mais) discos, mas será servido por um único. Seus resultados com o aumento do tamanho do registro Bonnie ++ mostram esse comportamento exato: a distribuição se beneficia muito com um tamanho maior de E / S.

Agora deve ficar claro que a combinação dos dois níveis de RAID em uma matriz RAID10 não levará ao dimensionamento linear do desempenho, mas define um limite superior para ele. Tenho certeza de que, se você executar várias instâncias do dd / bonnie ++ (ou usar fiopara manipular diretamente a fila de E / S), terá resultados mais alinhados com a expectativa original, simplesmente porque tributará sua matriz de E / S de uma maneira mais completa ( várias solicitações de E / S seqüenciais / aleatórias pendentes), em vez de carregá-lo apenas de solicitações de E / S seqüenciais únicas.