调整ZFS清理，以141KB / s的速度运行15天

14

一个相当基本的系统，在7.2k rpm sas磁盘上运行mirror + stripe，没有特别加载。无重复数据，压缩所有数据集。磨砂膏已经以死蜗牛的速度运转了15天。是否需要做一些优化，还是由于硬件故障？

  • 带有MD1200机箱的Dell R510。
  • 2个Xeon 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
    -------------------------  -----  -----  -----  -----  -----  -----  -----  -----

iostat是否告诉我，我花了更多的时间在等待磁盘上，而我本来应该这样做？特别是％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  nexenta 
— 3个
source
iostat -XnE会多次出现？grep错误说？错误计数会增加吗？
所有栏
— 均为
这是什么smartctl -A /dev/disk发言权大约每个驱动器（可能必须安装smartctl，不知道这是否带有底座安装）。
— 克里斯S
1
除了一个磁盘上的“非中型错误计数：8071”之外，没有其他有趣的内容。所有磁盘都位于同一（单个）SAS通道上的JBOD（Dell MD1200）中
— 3molo 2013年

Answers:

11

ZFS清理操作基于一些相当荒谬的原则进行操作。最值得注意的是，它仅在没有其他事情发生时才花费时间进行清理。如果您在一个相当恒定的基础上戳入一个只有少量数据访问权限的池，则清理将有效地使自己饿死并且几乎不执行任何操作。

要探索的可调参数，并附有简短的功能说明（不过，我最近才对此进行了研究）：

  • 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在清理操作上花费的最小毫秒数
  • zfs_no_scrub_io-没有注释
  • zfs_no_scrub_prefetch-没有注释，名称似乎暗示不导致对scrub ops进行预取

使用“ 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来禁用对scrub操作的预取，只是看看是否有帮助。如果不高兴，则取决于您所使用的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。与使用5/1作为默认设置的较早NexentaStor安装的默认设置相比，这告诉ZFS它可以在清理上花费更多的时间。小心，

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

— Nex7
source
我想我应该注意，您使用“ echo <tunable> / W0t <number> | mdb -kw”在bash中修改了这些设置。然后使用“ echo <tunable> / D | mdb -k”查看当前值。我的笔记说所有这些都可以在飞行中更改，似乎没有一个需要修改/ etc / system并重新启动才能生效。
— 2013年
我还应该在回答之前阅读整个问题-并在电话会议中停止浏览ServerFault。:)
— Nex7
报告的％b和asvc_t暗示正在进行一些非常非常随机的读取工作负载（如果磁盘确实是顺序的，则旋转磁盘的性能应比其更好）。首先，我将打开zfs_no_scrub_prefetch来禁用对scrub操作的预取，只是看看是否有帮助。如果不高兴，则取决于您所使用的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可能花费更长的时间进行
— 清理
我认为您提供了非常有价值的意见，但是如果您可以将评论添加到一个好的答案中，将会更有帮助。
— 3molo 2013年
2
进行更多调整可能有所帮助，但不一定。重要的是要注意，ZFS清理将滚动数据结构，而不是磁盘上的每个扇区。也就是说，根据zfs数据结构在磁盘上的显示方式，清理操作可能看起来非常随机-您的磁盘可能具有大于100 MB / s的顺序读取能力，但完全随机读取将完全是另一回事。平均块大小在这里也很重要。
— 2013年
3

我怀疑硬件...

为什么要让它运行15天？那不正常。停止擦洗- zpool scrub -s tank并检查系统。

  • 您正在使用哪些控制器？
  • 这是您在此泳池上运行过的第一次磨砂膏吗？
  • 是否有问题提示您首先运行磨砂膏？
— 怀特
source
1
LSI SAS9200-8e（IT固件）。不能先擦洗。不，没有实际问题（但是一段时间以来，我一直在质疑顺序读取/写入性能）。
— 3molo 2013年
更新了延迟和等待时间，开始怀疑总是需要一些时间来处理请求，并且将清理的优先级如此之低，以至于无法抓取。任何见解都非常有帮助！
— 3molo 2013年
磨砂对于定期运行很重要。等到您遇到运行清理问题时，该问题才被视为数据丢失。在那里可以进行清理以捕获无声数据损坏（bitrot）。运行缓慢的scrub并不是系统问题的迹象，而只是一个池，该池一直忙于不让scrub加速。
— lschweiss
0

我的回答来得有点晚，但是如果其他人遇到这种情况，这就是我的看法：只需尝试“ dmesg”。就我而言，我并没有进行清理，而是将文件复制到磁盘上，并且清楚地听到磁盘处于活动状态几秒钟，然后所有磁盘停止了更长的时间，然后又可以正常工作，依此类推。这是由于一个SATA控制器的故障而dmesg给了我所有的错误。起初我以为是故障磁盘，但后来我意识到它实际上是控制器。

— 吉头
source
-3

Scrub会利用可用的系统停机时间，即使在已卸载的服务器上也是如此，这与可用性有关。Ram和Processor是清除利用率的关键，而不是光盘。这些可用的越多，您的擦洗性能就越好。但是，当然，在这种情况下，就ZPools而言，光盘的布局越好，其清理性能也会越好。

因此，如果您的性能一直很慢，而且确实是这种情况，那么我会将其视为潜在的原因。

— 用户名
source
1
我看不到任何资源短缺的迹象。
— 3molo 2013年
1
这几乎是完全错误的。CPU和RAM对清理操作实际上是零影响（假设有任何可用空间）。拥有大量可用的RAM和CPU不会“加快”清理操作。通过查看池中传入的I / O，而不是通过检查“可用系统停机时间”来限制Scrub的运行。
— Nex7
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.