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

Question

Um sistema bastante básico rodando mirror + stripe em discos sams 7,2k rpm, não particularmente carregado. Nenhuma dedução, compactação em todos os conjuntos de dados. Esfrega tem funcionado por 15 dias à velocidade de um caracol morto. Existe alguma otimização que precisa ser feita, ou pode ser devido a alguma falha hw?

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

Algumas informações:

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, cerca de 20-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? 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 alta?

# 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

pre mdb tweak, observe a coluna b% 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

post 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

    

Answer 1

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

Tunables para explorar, com minhas anotações rápidas sobre o que faz (eu olhei pela última vez para este tempo, no entanto):

• zfs_scan_idle - se o I / O do usuário ocorrer nesse intervalo de tempo, delay scrub I / O por zfs_scrub_delay clock ticks
• zfs_scrub_delay - quantos toques de clock para atrasar a operação de limpeza se acionado por zfs_scan_idle
• zfs_top_maxinflight - número máximo de E / S de scrub por nível de vdev de nível superior
• zfs_scrub_limit - número máximo de E / S de limpeza por folha vdev
• zfs_scan_min_time_ms - mínimo de ms para gastar por txg no scrub operações
• zfs_no_scrub_io - sem notas
• zfs_no_scrub_prefetch - sem notas, nome parece implicar não causar pré-busca em operações de remoção

Tudo isso pode ser mudado na hora usando "echo [sintonizável] / W0t [número]" para alterar, e "ecoar [sintonizável] / D" para visualizar a configuração atual (que eu recomendo fazer antes de mudar).

Então, em teoria, e na prática geral, se você fosse, digamos, mudar zfs_scan_idle para 10 (ou 1 - ou 0, se ele suportasse isso, precisaria verificar o código) e zfs_scrub_delay para 1 (ou 0, se ele suportar isso), e se sua configuração txg_synctime_ms for 5000 ou mais, talvez mude um pouco o zfs_scan_min_time_ms, ele deve se tornar muito mais agressivo sobre fazer operações de scrub mesmo com algum nível de E / S de usuário.

No seu caso específico,% b e asvc_t relatados implicam em alguma carga de trabalho de leitura muito aleatória (os discos giratórios devem fazer melhor do que isso se for verdadeiramente sequencial), e você já fez o material "fácil" como explicado acima. Então, primeiro eu ativaria zfs_no_scrub_prefetch, para desabilitar a pré-busca em operações de scrub, apenas para ver se isso ajudou. Se não houver alegria, dependendo da versão do Nexenta em que você estiver - você pode estar executando 30/5, 5/1 ou 10/5 (que é 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, em seguida, tente aumentar zfs_scan_min_time_ms para 3000 ou 4000. Isso informa ao ZFS que pode gastar muito mais tempo com scrubs, em comparação com as configurações padrão em instalações mais antigas do NexentaStor que usam 5/1 como padrão - mas cuidado, isso pode passar fome E / S normal, se as configurações de atraso também foram definidas para basicamente 0!

Espero que isso ajude. Boa sorte!

    

Answer 2

Eu suspeito de hardware ...

Por que você deixaria isso funcionar por 15 dias? Isso não é normal. Pare o scrub - zpool scrub -s tank e verifique o sistema.

• Quais controladores você está usando?
• Este é o primeiro scrub que você já executou neste pool?
• Houve um problema que o levou a executar o scrub em primeiro lugar?

Answer 3

Minha resposta chega um pouco atrasada, mas se esse tipo de coisa acontecer com qualquer outra pessoa, aqui está minha opinião: simplesmente experimente o "dmesg". No meu caso, eu não estava fazendo um scrub, mas eu estava copiando arquivos para os discos, e eu estava ouvindo claramente os discos sendo ativos por alguns segundos, depois todos parando por mais tempo, e novamente trabalhando e assim por diante. Isto foi devido à falha de um controlador SATA e o dmesg me deu todos os erros. Eu pensei que era um disco com falha no início, mas depois percebi que era realmente o controlador.

    

Answer 4

O Scrub usa o tempo de inatividade do sistema disponível, mesmo em um servidor descarregado, é sobre a disponibilidade. Ram e Processor são as chaves para eliminar a utilização, não o disco. Quanto mais deles estiverem disponíveis, melhor será seu desempenho de limpeza. No entanto, certamente, neste caso, quanto melhores forem os seus discos, em termos de ZPools, melhor será o desempenho do seu scrub.

Então, se o seu desempenho tem sido lento, e parece ser esse o caso, eu considero essas razões potenciais.