一个非常基本的系统,在 7.2k rpm sas 磁盘上运行 mirror+stripe,没有特别加载。没有去重,对所有数据集进行压缩。Scrub 已经以一只死蜗牛的速度运行了 15 天。是否需要进行一些优化,或者可能是由于某些错误的硬件?
- 带 MD1200 机箱的 Dell R510。
- 2 个至强 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/w h/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。在这些写入之间,基本上没有读取或写入。
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/s w/s kr/s kw/s wait actv svc_t %w %b s/w h/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
延迟有点高?
# 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/s w/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/s w/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 清理操作基于一些相当脑残的原则。最值得注意的是,它只会在没有其他事情发生时才花时间擦洗。如果你在一个相当稳定的基础上只访问一个数据池,那么 scrub 将有效地饿死自己并且几乎什么都不做。
要探索的可调参数,以及我对它的作用的快速注释(不过,我最近一次研究过这个):
所有这些都可以使用“echo [tunable]/W0t[number]”进行更改,并使用“echo [tunable]/D”查看当前设置(我建议在更改之前这样做)。
所以在理论上,在一般实践中,如果你要,比如说,将 zfs_scan_idle 更改为 10(或 1 - 或 0,如果它支持,则需要检查代码)并将 zfs_scrub_delay 更改为 1(或 0,如果它支持),并且如果您的 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 安装的默认设置相比 - 但是小心,
希望这可以帮助。祝你好运!
我怀疑硬件...
你为什么要让它运行 15 天?这不正常。停止擦洗 -
zpool scrub -s tank
并检查系统。我的回答有点晚了,但如果这种事情发生在其他人身上,我的看法是:只需尝试“dmesg”。就我而言,我没有进行清理,而是将文件复制到磁盘,我清楚地听到磁盘活动了几秒钟,然后全部停止更长时间,然后再次工作等等。这是由于一个 SATA 控制器出现故障,dmesg 给了我所有的错误。起初我以为这是一个故障磁盘,但后来我意识到它实际上是控制器。
Scrub 使用可用的系统停机时间,即使在卸载的服务器上,它也是关于可用性的。Ram 和处理器是清理利用率的关键,而不是磁盘。这些可用的越多,您的擦洗性能就越好。但是,当然,在这种情况下,就 ZPools 而言,您的磁盘布局越好,您的擦洗性能也会越好。
所以,如果你的表现一直很慢,而且看起来确实如此,我会将这些视为潜在原因。