我正在尝试找出软件 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.60
iostat
表示磁盘并非 100% 繁忙(但只有 40-50%)。这符合最大值约为 80 MB/s 的假设。
由于这是软件突袭,限制因素可能是 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
显然分别占用了 64% 和 53% 的 CPU,但还没有接近 100%。
在测量了哪个块大小对 CPU 的消耗最小之后,选择了 RAID 的块大小(128k)。
如果这个速度正常:限制因素是什么?我能测量吗?
如果这个速度不正常:我如何找到限制因素?我能改变它吗?
答案1
我不记得从 4 磁盘 RAID 5 迁移到 6 磁盘 RAID 6 时的具体速度,但它们相似(4TB 可用阵列,24 小时重建,因此大约 45MB/s)。
您必须记住,即使speed_limit_min
将为尝试使用阵列的应用程序提供一些优先级。因此,用于检测活动的机制可能需要磁盘负载达到 50% 才能检测到它,并且仍然能够满足 IO 请求。您是否尝试过卸载分区?
要检查瓶颈,您必须跟踪内核(例如,使用 Linux Tracing Toolkitlttng
或 System Tap)。这并不容易,而且会花费大量时间,因此除非您必须在几台计算机上重建阵列,否则可能不值得。至于更改它:我相信 Linux 内核的此类补丁会受到欢迎 :)
答案2
我不会期望 Raid6 恢复操作具有顺序性,因为它通常需要从 n-1 个驱动器中恢复嵌入在这些驱动器上的数据块之间的校验和和数据块。
除此之外,我还期望有一个稍微连续的操作(=不是完全并行),例如:
- 读取数据块1
- 读取数据块2...
- 读取数据块 n-1
- 读取校验和1
- 计算数据块n
- 写入数据块
至少 5. 是同步点,因此持续时间(1..4) 至少为持续时间(最慢(1..4))。其执行效果如何取决于相关层 (md、驱动程序、控制器 (ncq 等)) 的并行化级别。
我绝不会期望 raid6 的重建率接近单个磁盘的连续读/写时间。
相比之下:我们的 PS6000 Equallogic 阵列(16x1TB)在中等负载下需要大约 32 小时来重建故障磁盘。