在 md RAID6 重建期间,一个磁盘的访问次数比其他磁盘多

在 md RAID6 重建期间,一个磁盘的访问次数比其他磁盘多

我正在重建 8 驱动器 RAID6 中的一个驱动器(使用“md”Linux 软件 RAID),并且注意到它似乎没有尽可能快地运行,大概是因为其中一个驱动器发送的 IOPS 是其他驱动器的两倍:

Device:            tps    kB_read/s    kB_wrtn/s    kB_read    kB_wrtn
sda             155.00     77252.00         0.00      77252          0
sdb             153.00     76736.00         0.00      76736          0
sdc             154.00     77248.00         0.00      77248          0
sde             154.00     77248.00         0.00      77248          0
sdf             164.00     77288.00         0.00      77288          0
sdd             154.00     77248.00         0.00      77248          0
sdg             287.00     83160.00         0.00      83160          0
sdh             146.00         0.00     74240.00          0      74240

(sdh 正在重建,并且 sdg 获得的 IOPS 比我预期的要多)。

(我使用 mdadm /dev/md1 --add /dev/sdh4 来添加替换驱动器,因为现有驱动器已发生故障/被删除)。

我已经消除的东西(我认为):

  1. 所有驱动器具有相同的分区布局(使用 sgdisk 复制)。

  2. sda-sdg 是具有相同型号的相同驱动器(sdh 是新的)。

  3. 我查看了所有驱动器上的预读、块大小和多重计数,没有发现 sdp 与其他驱动器有何差异。

  4. 在同一台机器上进行的不同重建也遇到了同样的问题(sdg 被访问得更多),所以这次我事先删除了写入意图位图,但这并没有帮助。

  5. 该主板 (ASRock P67 Extreme6) 具有奇怪的异构 SATA 配置,有两个 SATA3 端口和六个 SATA6 端口(两个来自芯片组,四个来自板载 Marvell SE9120 接口)。sdg 可能位于与 eSATA 插槽共享的端口上,但它声称与其他端口一样使用 UDMA6,所以我看不出这会产生什么影响。

知道为什么 sdg 上的 tps(IOPS)是其他的两倍吗?

更新:进一步澄清:

  1. 这些硬盘是 3 年前的 3TB Seagate Barracudas(虽然我通常不参与硬盘品牌的轶事,但 8 个硬盘中有一个出现故障,另外三个(但不是 sdg)显示出不良迹象(不可恢复的错误、多个重新分配的扇区):这些不是我用过的最可靠的硬盘)。`我很确定它们是无聊的 PMR。

  2. 一旦 RAID 恢复,访问现在均匀分布在所有磁盘上,每个驱动器的 IOPS 数量相似。因此,如果链接速度相关,我会感到惊讶(尽管我猜想 md 可能正在做奇怪的“优化”)。

  3. 在 RAID 完成恢复之前,我没有机会获取“iostat x”的输出,但从内存来看,sdg 的利用率为 100%,并且具有较大的请求队列大小(在 100 左右),而其他的利用率为 50-60%,并且具有个位数的请求队列大小。

我想我需要交换 sdg 和另一个驱动器才能完全消除它是控制器/md 还是驱动器。

更新 #2:不同的重建,相同的问题

这次我重建 sdb:

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda           13813.00     0.00  184.50    0.00    54.06     0.00   600.11    23.60  114.11  114.11    0.00   2.49  46.00
sdb               0.00 12350.50    0.00   97.50     0.00    48.62  1021.37     0.17    1.70    0.00    1.70   1.31  12.80
sdd           12350.00     0.00   98.00    0.00    48.62     0.00  1016.16     5.47   55.82   55.82    0.00   2.82  27.60
sdc           12350.00     0.00   98.00    0.00    48.62     0.00  1016.16     5.92   60.41   60.41    0.00   2.84  27.80
sde           12350.00     0.00   98.00    0.00    48.62     0.00  1016.16     6.11   62.39   62.39    0.00   3.02  29.60
sdf           12350.50     0.00   97.50    0.00    48.62     0.00  1021.37    14.56  149.33  149.33    0.00   3.92  38.20
sdg           12350.00     0.00   98.00    0.00    48.62     0.00  1016.16     7.18   73.31   73.31    0.00   3.16  31.00
sdh           12350.00     0.00   98.00    0.00    48.62     0.00  1016.16     5.27   53.80   53.80    0.00   2.88  28.20

如您所见,sda 获得的访问量比其他访问量多得多(我正在限制它,以便 sda 不会达到 100% 的利用率,尽管如果我不这样做,它就会达到 100%)。有趣的是,sda 的“avgrq-sz”(平均请求大小)较低,这表明额外的访问量要小得多。现在我只需要找到一种方法来找出它们是什么!

答案1

我最初的猜测是,md已经发现了问题sdg,并试图“尽快”从中提取数据,以便也可以进行替换。

但事实并非如此md(某些硬件控制器可能会这样做 - 不确定)。

阵列中的大量驱动器会减慢重建速度pdf - 来自重建从这个角度来看,阵列中的驱动器越少“越好”。

进一步探索可以得出一个可能的结论,以及一些后续问题:

  • 驱动器有多大?
  • 它们是什么类型——企业级还是台式机?
  • 它们是什么品牌——WD、Seagate、Hitachi、其他,还是混合?
  • 阵列中的驱动器类型是什么-PMR还是SMR?

由此审查希捷硬盘似乎使用 SMR 进行重建(更密集) 驱动器的速度异常不一致,而 PMR 则更加一致。

我的初步结论是

  1. 不同的 SATA 端口速度在这里没有帮助 - 我想,这对所有相关人员来说应该是显而易见的:)
  2. 您的阵列中要么有不同品牌的驱动器,要么这些驱动器非常大,或者它们不是为处理重建而设计的”更好的“(PMR)——或以上组合

相关内容