我试图在软件raid6的重建过程中找到瓶颈。
## Pause rebuilding when measuring raw I/O performance
# echo 1 > /proc/sys/dev/raid/speed_limit_min
# echo 1 > /proc/sys/dev/raid/speed_limit_max
## Drop caches so that does not interfere with measuring
# sync ; echo 3 | tee /proc/sys/vm/drop_caches >/dev/null
# time parallel -j0 "dd if=/dev/{} bs=256k count=4000 | cat >/dev/null" ::: sdbd sdbc sdbf sdbm sdbl sdbk sdbe sdbj sdbh sdbg
4000+0 records in
4000+0 records out
1048576000 bytes (1.0 GB) copied, 7.30336 s, 144 MB/s
[... similar for each disk ...]
# time parallel -j0 "dd if=/dev/{} skip=15000000 bs=256k count=4000 | cat >/dev/null" ::: sdbd sdbc sdbf sdbm sdbl sdbk sdbe sdbj sdbh sdbg
4000+0 records in
4000+0 records out
1048576000 bytes (1.0 GB) copied, 12.7991 s, 81.9 MB/s
[... similar for each disk ...]因此,我们可以顺序读取140 MB/s在外部轨道和82 MB/s在内部轨道在所有驱动器上同时。顺序写入性能相似。
这将使我期望重建速度为82 MB/s或更多。
# echo 800000 > /proc/sys/dev/raid/speed_limit_min
# echo 800000 > /proc/sys/dev/raid/speed_limit_max
# cat /proc/mdstat
md2 : active raid6 sdbd[10](S) sdbc[9] sdbf[0] sdbm[8] sdbl[7] sdbk[6] sdbe[11] sdbj[4] sdbi[3](F) sdbh[2] sdbg[1]
27349121408 blocks super 1.2 level 6, 128k chunk, algorithm 2 [9/8] [UUU_UUUUU]
[=========>...........] recovery = 47.3% (1849905884/3907017344) finish=855.9min speed=40054K/sec但我们只有40 MB/s,而且这个数字常常下降到30 MB/s。
# iostat -dkx 1
sdbc 0.00 8023.00 0.00 329.00 0.00 33408.00 203.09 0.70 2.12 1.06 34.80
sdbd 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdbe 13.00 0.00 8334.00 0.00 33388.00 0.00 8.01 0.65 0.08 0.06 47.20
sdbf 0.00 0.00 8348.00 0.00 33388.00 0.00 8.00 0.58 0.07 0.06 48.00
sdbg 16.00 0.00 8331.00 0.00 33388.00 0.00 8.02 0.71 0.09 0.06 48.80
sdbh 961.00 0.00 8314.00 0.00 37100.00 0.00 8.92 0.93 0.11 0.07 54.80
sdbj 70.00 0.00 8276.00 0.00 33384.00 0.00 8.07 0.78 0.10 0.06 48.40
sdbk 124.00 0.00 8221.00 0.00 33380.00 0.00 8.12 0.88 0.11 0.06 47.20
sdbl 83.00 0.00 8262.00 0.00 33380.00 0.00 8.08 0.96 0.12 0.06 47.60
sdbm 0.00 0.00 8344.00 0.00 33376.00 0.00 8.00 0.56 0.07 0.06 47.60iostat说磁盘不是100%忙(但只有40-50%)。这与假设最大值在80 MB/s左右是一致的。
由于这是软件raid,限制因素可能是CPU。top说:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
38520 root 20 0 0 0 0 R 64 0.0 2947:50 md2_raid6
6117 root 20 0 0 0 0 D 53 0.0 473:25.96 md2_resync因此,md2_raid6和md2_resync显然占据了CPU的64%和53%,而不是100%。
RAID的块大小(128 K)是在测量了哪个块大小给出的CPU最小惩罚后选择的。
如果这个速度是正常的:限制因素是什么?我能量一下吗?
如果这个速度是不正常的:我如何才能找到限制因素?我能改变一下吗?
发布于 2012-11-12 11:40:55
我不记得从4个磁盘RAID 5迁移到6个磁盘RAID 6时的速度,但它们是相似的(4TB可用阵列,24小时重建,所以大约45 so /S)。
您必须记住,即使是speed_limit_min也会对尝试使用数组的应用程序给予一定的优先级。因此,用于检测活动的机制可能需要在磁盘上加载50%的负载才能检测活动,并且仍然能够为IO请求提供服务。你试过卸载分区了吗?
要检查瓶颈,您必须跟踪内核(例如,使用Linux lttng或System )。这并不容易,而且要花很多时间,所以除非你不得不在几台计算机上重建数组,否则这可能不值得。至于修改它:我相信这样的补丁对Linux内核是受欢迎的:)
发布于 2012-11-12 13:09:44
我不认为Raid6恢复操作是连续的,因为它通常需要从n-1驱动器中恢复校验和,这些数据块嵌入在这些驱动器上的数据块之间。
除此之外,我还希望有一个有点连续的操作(=不完全并行),例如:
至少5.是同步点,因此持续时间(1.4)至少持续时间(最慢(1.4))。它的性能取决于任何涉及层(md、驱动程序、控制器(ncq等)的并行化程度)。
我绝不会期望raid6的重建速度接近单个磁盘的顺序读/写时间。
作为比较:我们的PS6000均衡器阵列(16x1TB)在中等负载下大约需要32小时才能重建一个失败的磁盘。
https://serverfault.com/questions/447787
复制相似问题