zfs send -i / receive stalling

2

Em uma instalação do Solaris 11.1, vejo quedas ao receber um fluxo incremental do zfs. Os fluxos são provenientes de uma instalação do Solaris 11.0, são criados usando zfs send -i e canalizados por mbuffer . Em algum momento, posso ver a ocorrência de gravação ocasionalmente (virtualmente nenhuma atividade de leitura ou gravação nos discos de destino, mpstat relatando a utilização no mesmo ou diferentes núcleos somando um pouco acima de 100% para "sistema"). 0 outra carga):

root@receiver:~# mpstat 5
[...]
 CPU minf mjf xcal  intr ithr  csw icsw migr smtx  srw syscl  usr sys  wt idl
   0    0   0    0   363  103  213    0    9    4    0    14    0   6   0  94
   1    0   0    0   113    3  149    0   11    6    0    16    0  12   0  88
   2    1   0    2    40    4   36    0    9    5    0     3    0   1   0  99
   3    0   0    0    82   59   18    0    2    3    0     3    0  93   0   7
 CPU minf mjf xcal  intr ithr  csw icsw migr smtx  srw syscl  usr sys  wt idl
   0    3   0    0   362  104  207    0    9    6    0    12    0  14   0  86
   1    0   0    0    90    4  109    0   10    7    0     3    0  17   0  83
   2    0   0    0    48    2   40    0    9    3    0     5    0  10   0  90
   3    0   0    0   100   54   44    0    7    3    0     4    0  69   0  31
 CPU minf mjf xcal  intr ithr  csw icsw migr smtx  srw syscl  usr sys  wt idl
   0    0   0    0   332  103   35    0    6    3    0     0    0  45   0  55
   1    0   0    0    27    3   22    0    3    1    0     0    0  45   0  55
   2    0   0    0   142    3  172    0    9    6    0     4    0  18   0  82
   3    0   0    0   181   56  178    0   10    6    0     8    0   1   0  99
 CPU minf mjf xcal  intr ithr  csw icsw migr smtx  srw syscl  usr sys  wt idl
   0    0   0    0   327  103   54    0    5    2    0     2    0  49   0  51
   1    0   0    0    46    3   52    0    9    3    0     0    0  28   0  72
   2    0   0    0   156    2  175    0    9    5    0     4    0  25   0  75
   3    0   0    0   153   62  132    1    8    6    0     5    0   3   0  97
 CPU minf mjf xcal  intr ithr  csw icsw migr smtx  srw syscl  usr sys  wt idl
   0    0   0    1   380  103  164    0   11    9    0     7    0   5   0  95
   1    0   0    0   144    3  165    0   11    9    0     6    0  25   0  75
   2    0   0    0    39    1   36    0    6    4    0     2    0  66   0  34
   3    0   0    0   125   77   55    0   10    6    0     1    0  14   0  86
 CPU minf mjf xcal  intr ithr  csw icsw migr smtx  srw syscl  usr sys  wt idl
   0    0   0    0   372  107  178    0    9    9    0    19    0   3   0  97
   1    0   0    0   145    3  193    0    9   10    0     8    0   8   0  92
   2    0   0    0    24    2   26    0    9    3    0     0    0   2   0  98
   3    0   0    0    94   86    3    0    0    5    0     0    0 100   0   0

Após outros 200 a 300 MB escritos em rajadas, a transferência quase pára:

root@receiver:~# zpool iostat tank 5
               capacity     operations    bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        1.85T  2.01T    511    831  7.76M  4.60M
tank        1.85T  2.01T      0     26      0  65.4K
tank        1.85T  2.01T      3     25  13.2K  62.4K
tank        1.85T  2.01T      4     34  5.00K  76.2K
tank        1.85T  2.01T      3     32  3.10K  87.0K
tank        1.85T  2.01T      0     25  1.20K  59.0K
tank        1.85T  2.01T      6     58  4.30K   339K
tank        1.85T  2.01T      1     28  3.70K  63.1K
tank        1.85T  2.01T     19     30  36.9K  83.2K

E os mbuffers nas extremidades de recebimento e envio estão em 100% de utilização.

Isso só parece acontecer com snapshots maiores (> 5G), mas vejo as baias no final do fluxo, depois que os primeiros GBs foram transferidos com sucesso em um tempo razoável. A recepção de fluxo ainda está funcionando, apenas muito lentamente - a taxa de dados está abaixo de 100 KB / s (da memória do lado receptor mbuffer para os discos ociosos) .

Eu também tentei tirar o mbuffer da equação e canalizar o fluxo zfs send através do SSH diretamente para o zfs receive , mas parece não fazer nenhuma diferença significativa. O instantâneo acaba sendo transferido, mas os últimos 1-2 shows levariam horas.

O host de recebimento é completamente ocioso, nenhuma mensagem é impressa no console, no log de mensagens do kernel ou / var / log / syslog naquele momento. O zpool de destino permanece utilizável - ainda posso acessar outros sistemas de arquivos localizados no mesmo zpool em todos os momentos. Além disso, o recebimento de fluxos zfs completos, não incrementais / não recursivos, de centenas de GB de tamanho funciona sem nenhum problema preceptível na velocidade do fio.

Existe algum problema conhecido com o 11.1 em relação a esse problema? Como eu poderia diagnosticar melhor o que o receptor está esperando quando deveria gravar o fluxo?

    
por the-wabbit 14.05.2013 / 11:41

1 resposta

4

Tanto o zfs send quanto o zfs receive estão ligados uns aos outros quando você os canaliza juntos assim. O sistema de origem deve rastrear os metadados do zfs procurando blocos que foram gravados no intervalo incremental que você está enviando. Você está canalizando isso para o mbuffer, de modo que o fluxo na sessão ssh possa ser um pouco otimizado, apresentando um intervalo em cada extremidade que pode mitigar a paralisação e excesso. Em seguida, o pipe do mbuffer envia dados para um zfs receive, que precisa processar os dados recebidos exatamente como se estivessem sendo gravados. Assim, X número de transações por grupo de transações, liberar para o disco, calcular os metadados e escrever tudo, até o uberblock. Isso pode parecer muito com baias no fluxo e geralmente pode durar de 5 a 30 segundos. Se essas quedas na taxa de transferência durarem mais de 30 segundos, você provavelmente estará ligado a algum lugar.

Dependendo de como seu sistema é ajustado, por exemplo, você tem um rápido ZIL SLOG? Ou você tem um número muito grande de fusos atrás do zpool para otimizar logbias = throughput? Dependendo das respostas a perguntas como essa, você poderá determinar se está vinculado a algum recurso ou não.

Seu CPUS não parece muito danificado. Eu vejo servidores diariamente com ZPOOLs dimensionados em 250 + TB que têm mpstat intr coluna conta mais de 20.000. Mais processadores sempre melhoram os números do mpstat.

Eu observaria alguns dos scripts do dtrace como zilstat , arcstat e iopattern entre outros (verifique o DtraceToolkit) para ver o que o sistema está fazendo durante suas pausas.

    
por 17.05.2013 / 22:39

Tags