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.