在7.2k rpm sas磁盘上运行mirror + stripe的一个非常基本的系统,没有特别的加载。 没有重复数据删除,压缩所有数据集。 磨砂已经以死亡蜗牛的速度运行了15天。 有一些需要完成的优化,还是可能是由于一些错误的硬件?
一些信息:
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。 在这些写入之间基本上没有读或写。
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我上次看了一下这个):
所有这些都可以使用“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一直很慢,而且确实如此,我会把这看作是潜在的原因。