调整ZFS擦洗，141KB / s运行15天

在7.2k rpm sas磁盘上运行mirror + stripe的一个非常基本的系统，没有特别的加载。没有重复数据删除，压缩所有数据集。磨砂已经以死亡蜗牛的速度运行了15天。有一些需要完成的优化，还是可能是由于一些错误的硬件？

带有MD1200机箱的戴尔R510。
2x至强E5620
48GB
NexentaStor 3.1.3，社区版

一些信息：

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/wh/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

每当我运行这个spa_last_io被改变

 # 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

每5秒钟写入约20-25 MB / s。在这些写入之间基本上没有读或写。

将ZFS服务器作为虚拟来宾进行托pipe

  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 ------------------------- ----- ----- ----- ----- ----- ----- ----- -----

iostats是否告诉我，我花更多时间等待磁盘，然后我应该？特别是％b列

 # iostat -xe device r/sw/s kr/s kw/s wait actv svc_t %w %bs/wh/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

低端的延迟是多less？

 # 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

应用一些调整，几乎没有什么区别。 zfs_top_maxinflight设置为127，zfs_scrub_delay设置为0，zfs_scan_idle设置为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

前mdb调整，注意相当高b％列

$ iostat -nx -M 5

  r/sw/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

后mdb调整，注意b％列，80-85％的时间在忙等待

 $ iostat -nx -M 5 r/sw/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

ZFS磨砂操作的操作基于一些相当无脑的原则。最值得注意的是，当没有别的事情发生的时候，它只会花时间擦洗。如果你只是在一个相当稳定的基础上访问数据库，那么灌丛就会有效地挨饿，几乎什么都不做。

可debugging的东西，用我的快速logging来探索它的function（尽pipe我上次看了一下这个）：

zfs_scan_idle – 如果用户I / O在这个多个时钟周期内发生，则通过zfs_scrub_delay时钟周期延迟清理I / O
zfs_scrub_delay – 如果由zfs_scan_idle触发，将延迟擦洗操作的时钟周期数
zfs_top_maxinflight – 每个顶级vdev的最大擦除I / O数目
zfs_scrub_limit – 每个叶子vdev的最大擦除I / O数目
zfs_scan_min_time_ms – 每个txg在清理操作上花费的最小ms数
zfs_no_scrub_io – 没有笔记
zfs_no_scrub_prefetch – 没有注释，名称似乎暗示不会导致刷洗操作上的预取

所有这些都可以使用“echo [tunable] / W0t [number]”来改变，“echo [tunable] / D”来查看当前的设置（我build议在改变之前进行）。

所以在理论上，在一般的实践中，如果你想把zfs_scan_idle降低到10（或1 – 或0，如果它支持的话，将需要检查代码）并且zfs_scrub_delay降低到1（或0，if它支持），如果你的txg_synctime_ms设置是5000或者更多，可能会把zfs_scan_min_time_ms修改一下，即使发生了一些用户I / O级别，它也应该变得更加激进。

在你的具体情况下，％b和asvc_t报告暗示了一些非常非常随机的读取工作量（旋转磁盘应该比如果它是真正的顺序做得更好），并且你已经完成了上面解释的“简单” 。所以，首先我打开zfs_no_scrub_prefetch，禁用预取刷洗操作，只是为了看看是否有帮助。如果没有喜悦，取决于您所使用的Nexenta版本 – 您可能正在运行30/5,5/1或10/5（这是我们用于设置zfs_txg_timeout＆（zfs_txg_synctime_ms * 1000）的速记）。将zfs_txg_timeout更改为10，将zfs_txg_synctime_ms更改为5000，然后尝试将zfs_scan_min_time_ms设置为3000或4000.这表明ZFS可以花费更多的时间进行擦除，而对于使用5/1作为默认设置的旧版NexentaStor安装的默认设置，小心，如果延迟设置也设置为0，则可能会导致正常的I / O操作。

希望这可以帮助。祝你好运！

我怀疑硬件…

你为什么让这个运行15天？这不正常。停止scrub- zpool scrub -s tank并检查系统。

你正在使用哪个控制器？
这是你在这个游泳池上运行的第一个磨砂膏吗？
是否有一个问题，促使你首先运行擦洗？

Scrub使用可用的系统停机时间，即使在卸载的服务器上，也是关于可用性。内存和处理器是擦洗利用率的关键，而不是光盘。这些可用的越多，你的磨砂性能就越好。不过，当然，在这种情况下，您的光盘放置得越好，就ZPool而言，您的擦洗性能也会越好。

所以，如果你的performance一直很慢，而且确实如此，我会把这看作是潜在的原因。