Linux软件RAID6:重建速度慢

前端之家收集整理的这篇文章主要介绍了Linux软件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 ...]

因此,我们可以在外部磁道上以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的假设.

由于这是软件raid,限制因素可能是cpu.顶部说:

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%.

在测量哪个chunksize给出最小的cpu惩罚之后,选择RAID的块大小(128k).

如果速度正常:限制因素是什么?我可以测量一下吗?

如果这个速度不正常:我怎样才能找到限制因素?我可以改变吗?

解决方法

我不记得从4磁盘RAID 5迁移到6磁盘RAID 6时的速度,但它们相似(4TB可用阵列,24小时重建,所以大约45MB / s).

您必须记住,即使是speed_limit_min也会为尝试使用该阵列的应用程序提供一些优先级.因此,用于检测活动的机制可能需要在磁盘上加载50%来检测它,并且仍然能够提供IO请求.你尝试卸载分区了吗?

要检查瓶颈,您必须跟踪内核(例如,使用Linux Tracing Toolkit lttng或System Tap).这并不容易,并且需要花费大量时间,除非你必须在几台计算机上重建阵列,否则它可能不值得.至于更改它:我确信欢迎使用Linux内核的这些补丁:)

猜你在找的Linux相关文章