Ajustando a depuração do ZFS, 141KB / s em execução por 15 dias

14

Um sistema bastante básico executando mirror + stripe em discos sas 7.2k rpm, não particularmente carregado. Sem redução de redundância, compactação em todos os conjuntos de dados. Scrub está em execução há 15 dias na velocidade de um caracol morto. Existe alguma otimização que precisa ser feita ou pode ser devido a algum problema de hw?

  • Dell R510 com gabinete MD1200.
  • 2x Xeon E5620
  • 48GB
  • NexentaStor 3.1.3, edição comunitária

Alguma informação:

scan: scrub in progress since Mon Apr  1 19:00:05 2013
171G scanned out of 747G at 141K/s, 1187h40m to go
0 repaired, 22.84% done
config:

    NAME                       STATE     READ WRITE CKSUM
    tank                       ONLINE       0     0     0
      mirror-0                 ONLINE       0     0     0
        c7t5000C500414FB2CFd0  ONLINE       0     0     0
        c7t5000C500414FCA57d0  ONLINE       0     0     0
      mirror-1                 ONLINE       0     0     0
        c7t5000C500415C3B1Bd0  ONLINE       0     0     0
        c7t5000C500415C5E4Fd0  ONLINE       0     0     0
      mirror-2                 ONLINE       0     0     0
        c7t5000C500415DC797d0  ONLINE       0     0     0
        c7t5000C500415DC933d0  ONLINE       0     0     0
    logs
      c7t5000A7203006D81Ed0    ONLINE       0     0     0
    cache
      c7t5000A72030068545d0    ONLINE       0     0     0


# iostat -en     
---- errors --- 
s/w h/w trn tot device
0 8887   0 8887 c2t0d0
0   0   0   0 c0t395301D6B0C8069Ad0
0   0   0   0 c7t5000C500415DC933d0
0   0   0   0 c7t5000A72030068545d0
0   0   0   0 c7t5000C500415DC797d0
0   0   0   0 c7t5000C500414FCA57d0
0   0   0   0 c7t5000C500415C3B1Bd0
0   0   0   0 c7t5000C500415C5E4Fd0
0   0   0   0 c7t5000C500414FB2CFd0
0   0   0   0 c7t5000A7203006D81Ed0

O spa_last_io é alterado toda vez que eu executo este

# echo "::walk spa | ::print spa_t spa_name spa_last_io spa_scrub_inflight" | mdb -k
spa_name = [ "syspool" ]
spa_last_io = 0x25661402
spa_scrub_inflight = 0
spa_name = [ "tank" ]
spa_last_io = 0x25661f84
spa_scrub_inflight = 0x21

A cada 5 segundos, aproximadamente 20 a 25 MB / s são gravados. Entre essas gravações, basicamente não há leituras ou gravações.

                          capacity     operations    bandwidth      latency
    pool                       alloc   free   read  write   read  write   read  write
    -------------------------  -----  -----  -----  -----  -----  -----  -----  -----
    syspool                     427G   501G      0      0      0      0   0.00   0.00
      c0t395301D6B0C8069Ad0s0   427G   501G      0      0      0      0   0.00   0.00
    -------------------------  -----  -----  -----  -----  -----  -----  -----  -----
    tank                        903G  1.84T    810  5.21K  1.50M  20.8M   9.42   4.71
      mirror                    301G   627G     22  1.00K  53.0K  3.96M   8.96   3.93
        c7t5000C500414FB2CFd0      -      -     20    244  50.1K  3.97M   6.70   1.14
        c7t5000C500414FCA57d0      -      -     19    242  48.2K  3.97M   7.60   1.12
      mirror                    301G   627G     25   1016  46.8K  4.10M  16.11   5.28
        c7t5000C500415C3B1Bd0      -      -     21    257  41.6K  4.11M   4.63   1.24
        c7t5000C500415C5E4Fd0      -      -     21    255  43.0K  4.11M  16.54   1.15
      mirror                    301G   627G     62    754   119K  3.03M  19.72   3.78
        c7t5000C500415DC797d0      -      -     57    219   114K  3.03M   9.99   1.15
        c7t5000C500415DC933d0      -      -     56    220   119K  3.03M  13.20   1.22
      c7t5000A7203006D81Ed0     260K  46.5G      0      0      0      0   0.00   0.00
    cache                          -      -      -      -      -      -
      c7t5000A72030068545d0    93.1G     8M      0      0      0      0   0.00   0.00
    -------------------------  -----  -----  -----  -----  -----  -----  -----  -----

Os iostats estão me dizendo que estou gastando mais tempo esperando pelo disco do que deveria? Especificamente a coluna% b

# iostat -xe
device    r/s    w/s   kr/s   kw/s wait actv  svc_t  %w  %b s/w h/w trn tot 
sd3       5.1   43.9   20.6  643.8  0.0  0.1    2.9   0   5   0   0   0   0 
sd4       9.4    1.8  141.1  169.6  0.0  0.0    0.5   0   0   0   0   0   0 
sd5       3.1   43.8   15.8  643.8  0.0  0.1    1.4   0   3   0   0   0   0 
sd6       5.2   38.1   14.3  494.4  0.0  0.1    3.0   0   7   0   0   0   0 
sd7       4.2   40.2   11.1  623.2  0.0  0.1    2.7   0   7   0   0   0   0 
sd8       3.6   44.3    9.7  623.2  0.0  0.1    1.5   0   4   0   0   0   0 
sd9       2.9   37.4    7.0  494.4  0.0  0.1    1.3   0   2   0   0   0   0 
sd10      0.7    0.4    3.4    0.0  0.0  0.0    0.0   0   0   0   0   0   0

A latência um pouco no lado alto?

# zpool iostat 10 10
               capacity     operations    bandwidth      latency
pool        alloc   free   read  write   read  write   read  write
tank         909G  1.83T     86  2.82K   208K  12.7M  22.68  13.63
----------  -----  -----  -----  -----  -----  -----  -----  -----
tank         909G  1.83T     29    857  42.4K  3.50M  17.86   4.47
----------  -----  -----  -----  -----  -----  -----  -----  -----
tank         909G  1.83T     30    947  46.1K  3.54M  15.55   5.67

Aplicou alguns ajustes que fizeram pouca diferença. zfs_top_maxinflight definido como 127, zfs_scrub_delay como 0 e zfs_scan_idle como 0.

# echo zfs_top_maxinflight | mdb -k
zfs_top_maxinflight:
zfs_top_maxinflight:            127

# echo zfs_scrub_delay/D |mdb -k
zfs_scrub_delay:
zfs_scrub_delay:0

# echo zfs_scan_idle/D |mdb -k
zfs_scan_idle:
zfs_scan_idle:  0


 scan: scrub in progress since Wed Apr 17 20:47:23 2013
    1.85G scanned out of 918G at 1.14M/s, 229h36m to go
    0 repaired, 0.20% done

ajuste pré-mdb, observe a coluna b% bastante alta

$ iostat -nx -M 5 

  r/s    w/s   Mr/s   Mw/s wait actv wsvc_t asvc_t  %w  %b device
  0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c2t0d0
  0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c0t395301D6B0C8069Ad0
 35.2   44.2    0.3    0.7  0.0  0.4    0.0    5.3   0  32 c7t5000C500415DC933d0
 19.8    3.2    0.2    0.0  0.0  0.0    0.0    0.1   0   0 c7t5000A72030068545d0
 31.2   46.2    0.2    0.7  0.0  0.3    0.0    4.4   0  27 c7t5000C500415DC797d0
 30.6   46.8    0.2    0.8  0.0  0.4    0.0    4.6   0  28 c7t5000C500414FCA57d0
 37.6   53.0    0.3    0.8  0.0  0.4    0.0    4.7   0  33 c7t5000C500415C3B1Bd0
 37.6   53.6    0.3    0.8  0.0  0.5    0.0    5.6   0  39 c7t5000C500415C5E4Fd0
 33.2   46.8    0.3    0.8  0.0  0.5    0.0    6.1   0  33 c7t5000C500414FB2CFd0
  0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c7t5000A7203006D81Ed0

pós mdb tweak, observe a coluna b%, 80-85% de tempo em espera ocupada

$ iostat -nx -M 5 
  r/s    w/s   Mr/s   Mw/s wait actv wsvc_t asvc_t  %w  %b device
  0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c2t0d0
  0.2   27.2    0.0    0.3  0.0  1.0    0.0   35.4   0  18 c0t395301D6B0C8069Ad0
129.6   20.2    0.9    0.4  0.0  2.9    0.0   19.5   0  85 c7t5000C500415DC933d0
 48.4    4.0    0.4    0.0  0.0  0.0    0.0    0.1   0   1 c7t5000A72030068545d0
130.4   19.8    0.9    0.4  0.0  3.0    0.0   20.2   0  84 c7t5000C500415DC797d0
125.8   25.8    0.9    0.5  0.0  2.9    0.0   19.2   0  80 c7t5000C500414FCA57d0
131.2   24.2    0.9    0.5  0.0  3.1    0.0   20.3   0  83 c7t5000C500415C3B1Bd0
130.6   25.8    0.9    0.5  0.0  3.5    0.0   22.5   0  88 c7t5000C500415C5E4Fd0
126.8   28.0    0.9    0.5  0.0  2.8    0.0   18.0   0  79 c7t5000C500414FB2CFd0
  0.2    0.0    0.0    0.0  0.0  0.0    0.0    0.1   0   0 c7t5000A7203006D81Ed0
zfs nexenta 3molo
fonte
Que ocorrência múltipla de iostat -XnE | grep Erros diz? algum erro conta incremento?
Zero em todas as colunas
3molo
O que smartctl -A /dev/diskdiz sobre cada unidade (pode ser necessário instalar smartctl, não tenho certeza se ele acompanha a instalação básica).
Chris S
1
Nada de interessante, além de "Contagem de erro não médio: 8071" em um disco. Todos os discos se sentar em um JBOD (Dell MD1200) no mesmo sas pista (single)
3molo

Respostas:

11

As operações de limpeza do ZFS operam com base em alguns princípios de morte cerebral. Mais notavelmente, ele só gasta tempo esfregando quando não há mais nada acontecendo. Se você vasculhar um pool com apenas um pouco de acesso a dados em uma base bastante constante, a limpeza efetivamente passará fome e não fará quase nada.

Ajustáveis ​​para explorar, com minhas notas rápidas sobre o que ele faz (eu olhei pela última vez há algum tempo atrás):

  • zfs_scan_idle - se a E / S do usuário ocorrer dentro de tantos toques de clock, atrase a E / S de limpeza por zfs_scrub_delay
  • zfs_scrub_delay - quantos ticks de relógio atrasam a operação de limpeza se acionados por zfs_scan_idle
  • zfs_top_maxinflight - número máximo de E / S de limpeza por vdev de nível superior
  • zfs_scrub_limit - número máximo de E / S de limpeza por vdev de folha
  • zfs_scan_min_time_ms - mínimo de ms para gastar por txg em operações de limpeza
  • zfs_no_scrub_io - sem notas
  • zfs_no_scrub_prefetch - sem notas, o nome parece implicar não causar pré-busca nas operações de depuração

Tudo isso pode ser alterado em tempo real usando "echo [sintonizável] / W0t [número]" para alterar e "echo [sintonizável] / D" para visualizar a configuração atual (o que eu recomendo fazer antes de alterar).

Portanto, na teoria e na prática geral, se você digitar, por exemplo, alterar zfs_scan_idle para 10 (ou 1 - ou 0, se for compatível com isso, precisaria verificar o código) e zfs_scrub_delay para 1 (ou 0, se suporta isso), e se a sua configuração txg_synctime_ms for 5000 ou mais, talvez altere um pouco o zfs_scan_min_time_ms, deve se tornar muito mais agressivo ao executar operações de limpeza mesmo com algum nível de E / S do usuário.

No seu caso específico, o% be asvc_t relatado implicam em uma carga de trabalho de leitura muito, muito aleatória (os discos giratórios devem fazer melhor do que isso se for realmente seqüencial), e você já fez as coisas "fáceis", como explicado acima . Então, primeiro eu ativaria zfs_no_scrub_prefetch, para desativar a pré-busca nas operações de limpeza, apenas para ver se isso ajudou. Se não houver alegria, dependendo da versão do Nexenta em que você está - você pode estar executando 30/5, 5/1 ou 10/5 (essa é uma abreviação que usamos para as configurações de zfs_txg_timeout & (zfs_txg_synctime_ms * 1000)). Altere zfs_txg_timeout para 10 e zfs_txg_synctime_ms para 5000 e tente aumentar o zfs_scan_min_time_ms para 3000 ou 4000. Isso indica ao ZFS que pode gastar muito mais tempo em scrubs, em comparação com as configurações padrão nas instalações mais antigas do NexentaStor que usam 5/1 como padrão - mas Cuidado,

Espero que isto ajude. Boa sorte!

Nex7
fonte
Acho que devo observar que você modifica essas configurações no bash usando "echo <tunable> / W0t <número> | mdb -kw". E você visualiza os valores atuais com "echo <tunable> / D | mdb -k". Minhas anotações dizem que tudo isso pode ser alterado durante o vôo, nenhum parece exigir uma modificação do sistema / etc / e reinicialização para entrar em vigor.
Nex7
Também devo ler a pergunta inteira antes de responder - e parar de navegar no ServerFault enquanto estiver em chamadas de conferência. :)
Nex7
O% be asvc_t relatados implicam em uma carga de trabalho de leitura muito, muito aleatória (os discos giratórios devem fazer melhor do que isso, se for realmente seqüencial). Primeiro, eu ativaria o zfs_no_scrub_prefetch, para desativar a pré-busca nas operações de limpeza, apenas para ver se isso ajudou. Se não houver alegria, dependendo da versão do Nexenta em que você está - você pode executar 30/5, 5/1 ou 10/5 (zfs_txg_timeout & (zfs_txg_synctime_ms * 1000). Altere zfs_txg_timeout para 10 e zfs_txg_synctime_ms para 5000 e tente aumentando zfs_scan_min_time_ms para 3000 ou 4000. Isto diz ZFS pode passar muito mais tempo no esfrega, podem morrer de fome e / S normal!
Nex7
Acho que você fornece informações muito valiosas, mas seria muito mais útil se você pudesse adicionar os comentários em uma boa resposta.
3molo
2
Mais ajustes podem ter ajudado, mas não necessariamente. É importante observar que uma limpeza do ZFS percorre a estrutura de dados, NÃO setor por setor nos discos. Ou seja, dependendo da aparência da estrutura de dados do zfs em seus discos, uma operação de limpeza pode parecer incrivelmente aleatória - seus discos podem ser capazes de> 100 MB / s de leitura seqüencial , mas a leitura completamente aleatória será outra história inteiramente . O tamanho médio do bloco também importaria aqui.
Nex7
3

Eu suspeito que o hardware ...

Por que você deixou isso funcionar por 15 dias? Isso não é normal. Pare a lavagem zpool scrub -s tanke verifique o sistema.

  • Quais controladores você está usando?
  • É a primeira vez que você corre nesta piscina?
  • Houve um problema que levou você a executar a limpeza em primeiro lugar?
ewwhite
fonte
1
LSI SAS9200-8e (firmware de TI). Não é o primeiro a esfregar. Não, não há problemas reais (mas venho questionando o desempenho sequencial de leitura / gravação há algum tempo).
3molo
Atualizado com latência e tempos de espera, começando a suspeitar que há sempre algum tempo para atender às solicitações, o que prioriza a limpeza tão baixa que é interrompida. Qualquer insight é muito útil!
3molo
Scrubs são importantes para executar periodicamente. Esperar até que você tenha um problema para executar uma limpeza está solicitando que esse problema se transforme em perda de dados. Os scrubs existem para detectar corrupção de dados silenciosa (bitrot). Uma limpeza em execução lenta não é um sinal de um problema no sistema, apenas um pool que é mantido ocupado o suficiente para não permitir que a limpeza acelere.
Lschweiss
0

Minha resposta chega um pouco tarde, mas se esse tipo de coisa acontece com mais alguém, aqui está a minha opinião: basta experimentar "dmesg". No meu caso, eu não estava limpando, mas estava copiando arquivos para os discos e ouvia claramente que os discos estavam ativos por alguns segundos, parando por mais tempo e depois trabalhando novamente. Isso ocorreu devido à falha de um controlador SATA e o dmesg me deu todos os erros. Eu pensei que era um disco com falha no começo, mas depois percebi que era realmente o controlador.

jytou
fonte
-3

O Scrub usa o tempo de inatividade do sistema disponível, mesmo em um servidor descarregado, é sobre disponibilidade. Ram e Processador são as chaves para limpar a utilização, não o disco. Quanto mais disponíveis, melhor será o desempenho da sua limpeza. No entanto, certamente, nesse caso, quanto melhor seus discos forem dispostos, em termos de ZPools, melhor será o desempenho de sua limpeza.

Portanto, se seu desempenho tiver sido lento, e esse parece ser o caso, eu consideraria esses possíveis motivos.

user169761
fonte
1
Não vejo nenhum indicador de que os recursos sejam escassos.
3molo
1
Isso é completamente completamente falso. CPU e RAM têm efetivamente zero impacto nas operações de limpeza (supondo que exista alguma livre). Ter muita RAM e CPU livres não 'acelera' as operações de limpeza. A limpeza é limitada observando E / S de entrada no pool, não verificando o tempo de inatividade do sistema disponível, seja o que for.
Nex7 27/05