2个驱动器,慢速软件RAID1(md)

我有一个从hetzner.de(EQ4)与2 *三星HD753LJ驱动器(750G 32MBcaching)的服务器。

OS是CentOS 5(x86_64)。 驱动器组合在一起成为两个RAID1分区:

  1. / dev / md0这是512MB大,只有/启动分区
  2. 700GB以上的/ dev / md1,是其他分区的一个大LVM

现在,我已经运行了一些基准testing,看起来即使是完全相同的驱动器,速度在每一个上都有所不同。

# hdparm -tT /dev/sda /dev/sda: Timing cached reads: 25612 MB in 1.99 seconds = 12860.70 MB/sec Timing buffered disk reads: 352 MB in 3.01 seconds = 116.80 MB/sec # hdparm -tT /dev/sdb /dev/sdb: Timing cached reads: 25524 MB in 1.99 seconds = 12815.99 MB/sec Timing buffered disk reads: 342 MB in 3.01 seconds = 113.64 MB/sec 

另外,当我运行例如。 pgbench这是重视IO相当沉重,我可以看到从iostat输出以下:

 Device: rrqm/s wrqm/sr/sw/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 231.40 0.00 298.00 0.00 9683.20 32.49 0.17 0.58 0.34 10.24 sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sda2 0.00 231.40 0.00 298.00 0.00 9683.20 32.49 0.17 0.58 0.34 10.24 sdb 0.00 231.40 0.00 301.80 0.00 9740.80 32.28 14.19 51.17 3.10 93.68 sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sdb2 0.00 231.40 0.00 301.80 0.00 9740.80 32.28 14.19 51.17 3.10 93.68 md1 0.00 0.00 0.00 529.60 0.00 9692.80 18.30 0.00 0.00 0.00 0.00 md0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 dm-0 0.00 0.00 0.00 0.60 0.00 4.80 8.00 0.00 0.00 0.00 0.00 dm-1 0.00 0.00 0.00 529.00 0.00 9688.00 18.31 24.51 49.91 1.81 95.92 Device: rrqm/s wrqm/sr/sw/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 152.40 0.00 330.60 0.00 5176.00 15.66 0.19 0.57 0.19 6.24 sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sda2 0.00 152.40 0.00 330.60 0.00 5176.00 15.66 0.19 0.57 0.19 6.24 sdb 0.00 152.40 0.00 326.20 0.00 5118.40 15.69 19.96 55.36 3.01 98.16 sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sdb2 0.00 152.40 0.00 326.20 0.00 5118.40 15.69 19.96 55.36 3.01 98.16 md1 0.00 0.00 0.00 482.80 0.00 5166.40 10.70 0.00 0.00 0.00 0.00 md0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 dm-1 0.00 0.00 0.00 482.80 0.00 5166.40 10.70 30.19 56.92 2.05 99.04 Device: rrqm/s wrqm/sr/sw/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 181.64 0.00 324.55 0.00 5445.11 16.78 0.15 0.45 0.21 6.87 sda1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sda2 0.00 181.64 0.00 324.55 0.00 5445.11 16.78 0.15 0.45 0.21 6.87 sdb 0.00 181.84 0.00 328.54 0.00 5493.01 16.72 18.34 61.57 3.01 99.00 sdb1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sdb2 0.00 181.84 0.00 328.54 0.00 5493.01 16.72 18.34 61.57 3.01 99.00 md1 0.00 0.00 0.00 506.39 0.00 5477.05 10.82 0.00 0.00 0.00 0.00 md0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 dm-1 0.00 0.00 0.00 506.39 0.00 5477.05 10.82 28.77 62.15 1.96 99.00 

这完全让我困惑。 为什么两个完全相同的驱动器在写入速度上有这样的差异(请参见util%)? 我之前没有真正关注过这些速度,所以也许这是正常的 – 如果有人能证实我会很感激。

否则,如果有人再次看到这样的行为,或知道是什么原因造成这样的行为,我真的很感谢答复。

我还会补充说明“smartctl -a”和“hdparm -I”输出是完全相同的,并不表示任何硬件问题。 较慢的驱动器已经改变了两次(到新的)。 另外,我要求更换驱动器的地方,然后SDA更慢,SDD更快(所以慢的一个是同一个驱动器)。 SATA电缆已经更换了两次。

你可以试试bonnie++基准testing工具吗? 你应该用内存大小的两倍来运行它(例如1GB):

 bonnie++ -s $((2*1024)) 

您的问题描述使我认为这是控制器不能轻松处理软件RAID1所做的并行写入。 在以下情况下使用上面的命令。 要检查这个假设是否属实,请做:

1)为每个硬盘单独的基准。 假设说结果是相似的。

2)基准RAID1。

3)在不同的磁盘上同时进行基准testing。 假设说,它应该看起来更像2)而不是1)。

祝你好运,
JoãoMiguel Neves

我同意你在磁盘之间的性能差距:看看队列大小的差异。 但是,我们还不知道是否要将磁盘本身或更高级别的磁盘归咎于它们。 几个实验:

  1. 使用sdb中的分区作为镜像的第一个元素,并使用sda的分区作为第二个分区:md3请参阅性能是否跟随磁盘或软件RAID。 (这会让我感到惊讶,但是在第二个实验需要(甚至是物理访问)之前,这可能是值得的。)

  2. 将连接物理上交换到sda和sdb。 如果性能现在改变,你应该责怪你的磁盘控制器。

我认为你的数据是正常的,它们是不同的,但只有很less的百分比。 我在其他许多相同的驱动器上看到过这种types的价值。

安德里亚

对不起,我在行尾徘徊了一下,也没有忽略你写的有关这两个驱动器的%util的区别。

不,这是不正常的,在你所说的话之后,我认为问题可能是控制器。 这两个chanenells是以相同的方式configuration的吗?

我会怀疑这次袭击是这个观察的一部分。 驱动器似乎显示几乎相同的w / s和wsec / s。 由于MD RAID将写入复制到连接到同一控制器的两个驱动器上,所以总线上的数据传输可能只发生一次,因此一个驱动器可能在CPU利用率方面达到顶峰,而另一个驱动器只是传输已经出现了来自控制器的块。 你有没有尝试重现没有MD RAID的行为?

可能是因为写意图位图? 它会导致RAID-1变慢。

closures写意图位图将提高写入RADI-1的速度,但也增加了在出现故障时重buildarrays的时间。

我在一个托pipe机构工作,过去我也遇到类似的问题,在数据传输速率方面,驱动器的利用率非常高,不应该超过驱动器。 通常,当我们看到我们将驱动器与另一个驱动器交换,RMA交换旧驱动器时。

联系您的托pipe服务提供商,让他们知道你有这个问题,看看他们是否可以交换与另一个驱动器,看看是否可以解决这个问题。 如果没有,可能是驱动器控制器问题。

您正在使用哪个电梯调度程序? 根据你的工作量,你可以尝试CFQ的最后期限。 根据内核的不同,有可能它已经启用Anticipatory调度程序,我发现它有md构造集的问题。

这可能是一个iostat问题或内核内核统计问题。 hdparm的数量似乎有点高, 审查发现这个hd有高达88mb / s的写速度。 它也可能是一个closuresNCQ,检查dmesg输出。

真正的testing是不用担心hds,并运行相同的基准,比如Bonnie ++。