在Solaris 11.1安装中，收到zfs增量stream时会看到停顿。 stream源自Solaris 11.0安装，使用zfs send -i创build并通过mbufferpipe道mbuffer 。 在某些时候，偶尔会看到写性能停顿（实际上在目标磁盘上没有读或写操作， mpstat报告相同或不同核心上的利用率mpstat略高于“系统”的100％，其他0个加载）：
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
在连发200-300MB之后，转移几乎停止了：
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
接收端和发送端的mbuffers使用率为100％。
这似乎只发生在更大的（> 5G）快照上，在确定了第一个GB在合理的时间内成功传输之后，我确实看到了stream尾的停顿。 数据stream接收仍在工作，速度非常缓慢 – 数据速率低于100 KB / s（从接收方mbuffer的内存到空闲磁盘）。
我也尝试了将mbuffer排除在等式之外，并通过SSH将zfs sendstream直接传送到zfs receive ，但似乎没有什么区别。 快照最终得到转移，但最后1-2演出需要数小时。
接收主机是完全空闲的，当时没有消息打印到控制台，内核消息日志或/ var / log / syslog。 目标zpool保持可用 – 我仍然可以随时访问位于同一个zpool中的其他文件系统。 而且，接收数百GB的完整，非增量/非recursionzfsstream，在线速度下不会出现任何先前的问题。
有关这个问题的11.1是否有一个已知的问题？ 我应该如何进一步诊断接收器在写入数据stream时等待什么？
当你把它们连接在一起的时候，zfs send和zfs receive是相互关联的。 源系统必须抓取zfs元数据，查找在发送的增量间隔内写入的块。 然后，你将其pipe理到mbuffer，以便通过在每个端点上提供一个桶来缓解拖延和溢出，通过ssh会话的stream可以进行一些优化。 然后，来自mbuffer的pipe道将数据馈送到一个zfs接收器，该接收器必须像处理正在写入的数据一样处理传入的数据。 因此，每个事务组的X个事务，刷新到磁盘，计算元数据，并将其全部写出，一直到uberblock。 这可以看起来非常像stream中的摊位，一般可以持续5到30秒。 如果这些吞吐量的下降持续时间超过30秒，那么你可能会在某处find资源。
例如，根据您系统的调整方式，您是否拥有快速的ZIL SLOG？ 或者你的zpool后面有很多的主轴来优化logbias =吞吐量？ 根据这样的问题的答案，你将能够确定你是否在某个地方的资源绑定。
你的CPUS看起来不是太糟糕了。 我每天都看到服务器上的ZPOOL大小为250 + TB，其中mpstat intr列数超过了20,000。 更多的CPU总是改善mpstat数字。
我会查看一些dtrace脚本，如zilstat ， arcstat和iopattern等（请查看DtraceToolkit），以查看暂停期间系统正在执行的操作。