Ole*_*nge 5 linux performance mdadm software-raid raid6
我试图找到重建软件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 ...]
Run Code Online (Sandbox Code Playgroud)
因此,我们可以同时以 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
Run Code Online (Sandbox Code Playgroud)
但我们只能得到 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
Run Code Online (Sandbox Code Playgroud)
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
Run Code Online (Sandbox Code Playgroud)
So md2_raid6andmd2_resync显然分别忙于占用 CPU 的 64% 和 53%,但还没有接近 100%。
RAID 的块大小 (128k) 是在测量哪个块大小给 CPU 损失最少后选择的。
如果这个速度是正常的:限制因素是什么?我可以测量吗?
如果这个速度不正常:如何找到限制因素?我可以改变吗?
我不太记得从 4 磁盘 RAID 5 迁移到 6 磁盘 RAID 6 时的速度,但它们是相似的(4TB 可用阵列,24 小时重建,所以大约 45MB/s)。
您必须记住,即使是speed_limit_min尝试使用该阵列的应用程序也会给予一定的优先级。因此,用于检测活动的机制可能需要磁盘上有 50% 的负载来检测它,并且仍然有能力服务 IO 请求。您是否尝试卸载分区?
要检查瓶颈,您必须跟踪内核(例如,使用 Linux Tracing Toolkitlttng或 System Tap)。这并不容易,并且需要花费大量时间,因此除非您必须在几台计算机上重建阵列,否则可能不值得。至于改变它:我确信 Linux 内核的此类补丁会受到欢迎:)