文章简介：每周六 11:00 定时出现的 IO 延迟，最终定位到 Raid 卡的后台一致性检查（CC & PR）。关闭后延迟消失，复盘记录在此。
机器机器 raid 信息
调整前磁盘 etcd 的 grep -E '(apply request took too lon)|(slow fdatasyn)' took 趋势：
客户现场的机器是浪潮的整机，信息如下：
根据 io 延迟的出现时间，判断每周六的 11:00 出现的定时任务；
- 业务层排查：无对应定时任务
- 宿主机排查：无异常进程
- 怀疑硬件与厂商确认：Raid 卡默认每周六 11:00 运行 Consistency Check（CC）与 Patrol Read（PR）
关闭后 etcd 的延迟几乎消失：
在内网找了 3 台同型号机器（Raid 卡：AVAGOMegaRAIDSAS9361-8i），400 GB SSD RAID 1 平均 Disk Average Wait Time：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
|
[root@TODO storcli]# ./storcli64 /c0 show
----------------------------------------------------------------------------------------
EID:Slt DID State DG Size Intf Med SED PI SeSz Model Sp Type
----------------------------------------------------------------------------------------
252:0 14 Onln 0 446.625 GB SATA SSD N N 512B SAMSUNG MZ7LH480HAHQ-00005 U -
252:1 15 Onln 0 446.625 GB SATA SSD N N 512B SAMSUNG MZ7LH480HAHQ-00005 U -
252:2 8 Onln 1 7.276 TB SATA HDD N N 512B ST8000NM000A-2KE101 U -
252:3 9 Onln 1 7.276 TB SATA HDD N N 512B ST8000NM000A-2KE101 U -
252:5 11 Onln 1 7.276 TB SATA HDD N N 512B ST8000NM000A-2KE101 U -
252:6 12 Onln 1 7.276 TB SATA HDD N N 512B ST8000NM000A-2KE101 U -
252:7 13 Onln 1 7.276 TB SATA HDD N N 512B ST8000NM000A-2KE101 U -
----------------------------------------------------------------------------------------
[root@TODO storcli]# ./storcli64 /c0 show cc
CLI Version = 007.3404.0000.0000 April 18, 2025
Operating system = Linux 3.10.0-1160.el7.x86_64
Controller = 0
Status = Success
Description = None
Controller Properties :
=====================
-----------------------------------------------
Ctrl_Prop Value
-----------------------------------------------
CC Operation Mode Concurrent
CC Execution Delay 168 hours
CC Next Starttime 07/26/2025, 03:00:00
CC Current State Stopped
CC Number of iterations 164
CC Number of VD completed 2
CC Excluded VDs None
-----------------------------------------------
[root@TODO storcli]# ./storcli64 /c0 show pr
CLI Version = 007.3404.0000.0000 April 18, 2025
Operating system = Linux 3.10.0-1160.el7.x86_64
Controller = 0
Status = Success
Description = None
Controller Properties :
=====================
---------------------------------------------
Ctrl_Prop Value
---------------------------------------------
PR Mode Auto
PR Execution Delay 168 hours
PR iterations completed 120
PR Next Start time 07/26/2025, 03:00:00
PR on SSD Disabled
PR Current State Stopped
PR Excluded VDs None
PR MaxConcurrentPd 248
---------------------------------------------
|
ssd 上已经 disable 了 PR，只有 cc，看起来 cc 给磁盘带来了大约 5ms ± 15ms 左右的 iowait，而客户这边 io wait 跟比这要高非常多。
参考：浅谈 Raid 卡的两种一致性校验方式（PR&CC）
找了硬件厂商的人，反馈回来：
1
2
3
4
|
因 CC 和 PR 校验会影响硬盘 IO，不同业务环境对延迟敏感程度不同，系统下受影响的现象不同，目前推荐如下：
1. CC 周期推荐 28 天执行一次，默认 Cc rate 为 30%，这个 30% 是一个大约的 CPU 时间占用比例，由这个 rate 决定多久进行一次 Cc 的后台动作，但是即使降到 0 也会占用一点 CPU，因为 CC 必须要做。（目前已调整至 5%，已经最低）
2. 如实际业务对延迟较敏感，请评估是否关闭 CC。关闭 CC 后，因 CC 带来的 IO 性能和延迟影响得到改善。建议参考 CC 对性能和数据安全的影响进行综合评估。关闭 CC 后，在遇到盘端有介质错误的时候，RAID 卡端会花费更多的时间来尝试读取数据并标记修复异常数据，可能造成延迟升高，严重情况下，如果同条带中多个数据错误可能会导致数据丢失。
|
接下来继续等待硬件厂商的 debug 结果吧。
后续
- 等待厂商进一步 debug
- 对 etcd 场景而言，已有 snapshot + 12 h 备份，可直接关闭 CC 以换取确定性低延迟
- 是否可将 etcd 数据目录直接放 tmpfs？需评估内存容量与断电风险
结论
Raid 卡不是免费的午餐，后台维护任务同样消耗资源。在延迟敏感型业务中，需要显式权衡数据安全与性能。
