Eu tenho uma pergunta relacionada a esse problema, mas ficou muito complicado e grande, então decidi dividir o problema em NFS e problemas locais. 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
Resumo: como estou configurado e o que estou esperando
- Eu tenho um pool ZFS com 4 discos. 2TB RED configurado como 2 mirrors que são distribuídos (RAID 10). No Linux, zfsonlinux. Não há dispositivos de cache ou log.
- Os dados são balanceados entre espelhos (importante para ZFS)
- Cada disco pode ler (raw w/dd) a 147 MB/s em paralelo, proporcionando uma taxa de transferência combinada de 588 MB/s.
- Espero cerca de 115 MB/s de gravação, 138 MB/s de leitura e 50 MB/s de reescrita de dados sequenciais de cada disco, com base em benchmarks de um disco RED de 4 TB semelhante. Espero nada menos que 100 MB/s de leitura ou gravação, já que qualquer disco pode fazer isso hoje em dia.
- Achei que veria 100% de utilização de E/S em todos os 4 discos ao ler ou gravar dados sequenciais sob carga. E que os discos estariam produzindo mais de 100 MB/s com 100% de utilização.
- Achei que o pool me daria cerca de 2x gravação, 2x reescrita e 4x desempenho de leitura em um único disco - estou errado?
- NOVO Achei que um ext4 zvol no mesmo pool teria a mesma velocidade que o ZFS
O que eu realmente recebo
Acho que o desempenho de leitura do pool 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 sequencial- --Aleatório- Simultaneidade 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Busca-- 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 sequencial- --Aleatório- Simultaneidade 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Busca-- 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 uma única unidade RED de 4 TB (são o dobro). 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 cerca de 260 MB/s
bonnie++ na piscina a partir de agora, enquanto reunia as informações abaixo. Não exatamente como antes, e nada mudou.
Versão 1.97 ------Saída sequencial------ --Entrada sequencial- --Aleatório- Simultaneidade 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Busca-- 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
zpool iostat durante a gravação. Parece bom para mim.
largura de banda de operações de capacidade
pool alloc livre leitura 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
zpool iostat durante a reescrita. Parece ok para mim, eu acho .
largura de banda de operações de capacidade
pool alloc livre leitura gravação leitura gravação
-------------------------------------------- ----- - ---- ----- ----- ----- -----
pool2 1,27T 2,35T 1015 923 125M 101M
espelho 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
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 eu me pergunto o que está acontecendo
zpool iostat durante a leitura
largura de banda de operações de capacidade
pool alloc livre leitura 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 IO% não está em 100%.
Dispositivo: rrqm/s wrqm/sr/sw/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 do conjunto de dados de teste:
- um tempo está desligado
- a compressão está desligada
- ashift é 0 (detecção automática - meu entendimento foi que estava tudo bem)
- zdb diz que os discos estão todos ashift = 12
- módulo - opções zfs zvol_threads=32 zfs_arc_max=17179869184
- sincronizar = padrão
Editar - 30 de outubro de 2015
fiz mais alguns testes
- conjunto de dados bonnie++ w/recordsize=1M = 226 MB de gravação, 392 MB de leitura muito melhor
- conjunto de dados dd com tamanho do registro = 1M = gravação de 260 MB, leitura de 392 MB muito melhor
- zvol w/ext4 dd bs=1M = 128 MB de gravação, 107 MB de leitura, por que tão lento?
- conjunto de dados 2 processos em paralelo = gravação de 227 MB, leitura de 396 MB
- dd direct io não faz diferença no conjunto de dados e no zvol
Estou muito mais feliz com o desempenho com o aumento do tamanho do disco. Quase todos os arquivos no pool têm mais de 1 MB. Então vou deixar assim. Os discos ainda não estão obtendo 100% de utilização, o que me faz pensar se ainda poderia ser muito mais rápido. E agora estou me perguntando por que o desempenho do zvol é tão ruim, já que é algo que eu uso (levemente).
Fico feliz em fornecer qualquer informação solicitada nos comentários/respostas. Também há toneladas de informações postadas em minha outra pergunta: Cópia lenta entre diretórios NFS/CIFS no mesmo servidor
Estou plenamente consciente de que posso simplesmente não entender alguma coisa e que isso pode não ser um problema. Desde já, obrigado.
Para deixar claro, a pergunta é: por que o pool ZFS não é tão rápido quanto eu esperava? E talvez haja mais alguma coisa errada?
Consegui obter velocidades muito próximas dos números que esperava.
Eu estava procurando por 400 MB/s e gerenciei 392 MB/s . Então eu digo que é problema resolvido. Com a adição posterior de um dispositivo de cache, gerenciei 458 MB / s de leitura (em cache, acredito).
1. Inicialmente , isso foi alcançado simplesmente aumentando o
recordsizevalor do conjunto de dados ZFS para1MAcredito que essa alteração resulta apenas em menos atividade de disco, portanto, grandes leituras e gravações síncronas mais eficientes. Exatamente o que eu estava pedindo.
Resultados após a mudança
2. Fiquei ainda melhor quando adicionei um dispositivo de cache (SSD de 120 GB). A gravação é um pouco mais lenta, não sei por quê.
O truque com o dispositivo de cache era definir
l2arc_noprefetch=0em /etc/modprobe.d/zfs.conf . Ele permite que o ZFS armazene em cache dados sequenciais/de streaming. Só faça isso 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 em meu conjunto de dados, pensei que poderia ser uma maneira semelhante de lidar com o baixo desempenho do zvol.
Me deparei com várias pessoas comentando que obtiveram bom desempenho usando um
volblocksize=64k, então experimentei. Sem sorte.Mas então li que o ext4 (o sistema de arquivos com o qual estava testando) suporta opções para RAID como
strideestripe-width, que nunca usei antes. Então usei este site para calcular as configurações necessárias: https://busybox.net/~aldot/mkfs_stride.html e formatei o zvol novamente.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 a 6 vezes mais rápidos para gravações, pelo que me lembro. Vou atualizar esta resposta novamente se eu comparar novamente.Seus resultados são perfeitamente razoáveis, enquanto sua expectativa nã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 do mundo real pode estar em qualquer lugar entre 1x-2x.
Vamos esclarecer com um exemplo. Imagine ter um sistema com espelho de 2 vias, 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), esta matriz não terá vantagem sobre um único disco: RAID1 divide as solicitações de E/S na fila de dois discos, mas não divide uma única solicitação em dois discos (pelo menos, qualquer implementação que vi se comportar dessa maneira). Por outro lado, se sua fila de E/S for maior (por exemplo: você tem 4/8 solicitações pendentes), a taxa de transferência total do disco será significativamente maior do que a de um único disco.
Um ponto semelhante pode ser feito para 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 IO : se o tamanho médio de IO for menor que o tamanho do bloco, ele não será distribuído em dois (ou mais) discos, mas será servido por um único. Seus resultados com o tamanho de registro Bonnie++ aumentado mostram esse comportamento exato: o striping se beneficia muito de um tamanho de E/S maior.
Agora deve ficar claro que a combinação dos dois níveis de RAID em uma matriz RAID10 não levará a um dimensionamento de desempenho linear, mas definirá um limite superior para isso. Tenho certeza de que, se você executar várias instâncias de dd/bonnie++ (ou usar
fiopara manipular diretamente a fila de IO), terá resultados mais alinhados com sua expectativa original, simplesmente porque taxará sua matriz de IO de maneira mais completa ( várias solicitações de IO sequenciais/aleatórias pendentes), em vez de carregá-lo apenas com solicitações de IO sequenciais únicas.As gravações do zfs não são muito rápidas, mas não são ruins. as leituras do zfs são extremamente lentas, dê uma olhada por conta própria: 1) #Preparation: cd /mytestpool/mytestzfs;for f in urf{0..9};do dd if=/dev/urandom of=$f bs=1M count =102400;concluído; #Obtenha um caminho de diretório com muitos subdiretórios e arquivos (de ~ 50 GB) e verifique o tamanho com, por exemplo: du -sh /mytestpool/mytestzfs/appsdir 2) reboot 3) time cat /mytestpool/mytestzfs/urf0 >/dev/null; data;for f in /mytestpool/mytestzfs/urf{1..9};do cat $f >/dev/null & wait;done;date ; time tar cf - /mytestpool/mytestzfs/appsdir|cat - >/dev/null 4) #Olhe para iostat, iotop ou zpool iostat: você vê muito lá! 5) Depois que as leituras forem concluídas, pegue uma calculadora e divida o tamanho de arquivo único/s, divida 9x o tamanho de arquivo único/s e divida o tamanho do diretório/s. Este'