zfs send -i / receive stalling

Question

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?

    

Answer 1

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.