4、 一次 Ceph OSD 高时延排查复盘：BlueStore db/wal 介质选择不当引发的小 IO 时延问题
·
文章目录
前言
最近在处理一套 Ceph 存储集群时，遇到了一个比较典型但又容易误判的问题：集群整体健康正常，没有明显硬件故障，也不存在大规模 PG 异常，但部分 OSD 的时延始终偏高。好在这套集群刚搭建完成，尚未承接正式业务，因此有比较充足的排查和验证空间。
一开始，这类问题很容易被怀疑为 Ceph 参数、网络抖动、硬盘故障，甚至软件 Bug。但这次排查下来，根因既不是软件缺陷，也不是单纯的硬件损坏，而是机械盘直通部署方式下，底层写确认路径与 BlueStore 的小块同步写模型不匹配。本文记录一下这次排查思路、关键证据和最终结论。
一、问题现象
集群整体健康正常，但机械硬盘承载的 OSD 的 commit/apply latency 持续偏高，普遍在 20~30ms，个别 OSD 可达 30ms+；相比之下，承载在 SSD 上的 OSD 时延基本为 0ms。
[root@HB-TJ-SDS-R4900G3-4110-001 ~]# ceph osd perf | (read -r header; echo "$header"; tail -n +2 | sort -k3 -nr)
osd commit_latency(ms) apply_latency(ms)
22 37 37
16 34 34
37 33 33
26 33 33
24 33 33
18 33 33
42 32 32
40 31 31
47 30 30
39 30 30
35 30 30
20 30 30
14 30 30
45 29 29
30 29 29
28 29 29
23 29 29
41 28 28
44 27 27
34 27 27
32 27 27
15 27 27
13 27 27
46 26 26
43 23 23
31 23 23
27 22 22
38 21 21
33 21 21
17 19 19
12 18 18
9 0 0
8 0 0
7 0 0
6 0 0
59 0 0
58 0 0
57 0 0
56 0 0
55 0 0
54 0 0
53 0 0
52 0 0
51 0 0
50 0 0
5 0 0
49 0 0
48 0 0
4 0 0
36 0 0
3 0 0
29 0 0
25 0 0
2 0 0
19 0 0
11 0 0
10 0 0
1 0 0
0 0 0
从现象上看，问题并不是随机发生，而是与 OSD 所在介质类型存在明显相关性。这意味着排查重点不能只停留在 Ceph 集群层，而要继续下沉到底层介质和写入路径。
二、排查思路
1. 先排除集群级故障
先看 ceph -s。结果显示：
- MON 仲裁正常
- PG 全部 active+clean
- 集群整体 HEALTH_OK
虽然排查期间有部分机械盘承载的 OSD 因高时延被自动隔离（out出去），但这更像是高时延带来的结果，而不是根因本身。
[root@HB-TJ-SDS-R4900G3-4110-001 ~]# ceph -s
cluster:
id: bc2e4d8d-bf50-4e0f-80e5-5d86e922d9c1
health: HEALTH_OK
services:
mon: 3 daemons, quorum HB-TJ-SDS-R4900G3-4110-004,HB-TJ-SDS-R4900G3-4110-005,HB-TJ-SDS-R4900G3-4110-006
osd: 60 osds: 57 up, 57 in; 1 remapped pgs
flags noscrub
data:
pools: 2 pools, 3072 pgs
objects: 2 objects, 0
usage: 11137M used, 288T / 288T avail
pgs: 3072 active+clean
这一步可以先确认：问题不在 Ceph 集群整体健康状态，而在局部 OSD 的时延异常。
2. 排除 CPU、内存、网络和时钟问题
继续检查节点资源：
- CPU idle 很高
- iowait 接近 0
- 内存充足
- 未使用 swap
[root@HB-TJ-SDS-R4900G3-4110-001 ~]# top
top - 15:45:03 up 27 days, 21:47, 1 user, load average: 2.21, 2.41, 2.79
Tasks: 659 total, 1 running, 658 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.8 us, 1.0 sy, 0.0 ni, 97.5 id, 0.0 wa, 0.5 hi, 0.3 si, 0.0 st
MiB Mem : 128052.8 total, 10587.4 free, 37909.0 used, 89828.7 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 90143.8 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
4042767 root 20 0 27400 6104 3832 R 16.7 0.0 0:00.04 top
118484 root 20 0 3676268 1.5g 24764 S 8.3 1.2 39,33 ant-queen
1210338 root 20 0 353816 127196 41756 S 8.3 0.1 14,18 fdbserver
1905605 root 20 0 2153580 997.0m 36108 S 8.3 0.8 8,20 ceph-osd
1905629 root 20 0 2150512 1.0g 35932 S 8.3 0.8 8,43 ceph-osd
1911142 root 20 0 2349880 1.1g 36292 S 8.3 0.8 9,39 ceph-osd
1911389 root 20 0 2343624 1.1g 36296 S 8.3 0.9 9,20 ceph-osd
1911537 root 20 0 2330240 1.1g 36284 S 8.3 0.9 9,17 ceph-osd
1 root 20 0 184248 14404 8552 S 0.0 0.0 60:06.23 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:04.76 kthreadd
3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp
4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par_gp
6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/0:0H-kblockd
9 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_percpu_wq
10 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_tasks_rude_
11 root 20 0 0 0 0 S 0.0 0.0 0:00.00 rcu_tasks_trace
12 root 20 0 0 0 0 S 0.0 0.0 1:52.27 ksoftirqd/0
13 root 20 0 0 0 0 I 0.0 0.0 30:06.57 rcu_sched
14 root rt 0 0 0 0 S 0.0 0.0 0:08.70 migration/0
15 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/0
16 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/1
17 root rt 0 0 0 0 S 0.0 0.0 0:08.25 migration/1
18 root 20 0 0 0 0 S 0.0 0.0 1:39.60 ksoftirqd/1
20 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/1:0H-kblockd
21 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/2
22 root rt 0 0 0 0 S 0.0 0.0 0:08.06 migration/2
23 root 20 0 0 0 0 S 0.0 0.0 1:51.79 ksoftirqd/2
25 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/2:0H-events_highpri
26 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/3
27 root rt 0 0 0 0 S 0.0 0.0 0:07.84 migration/3
28 root 20 0 0 0 0 S 0.0 0.0 1:40.47 ksoftirqd/3
30 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/3:0H-events_highpri
31 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/4
32 root rt 0 0 0 0 S 0.0 0.0 0:07.83 migration/4
33 root 20 0 0 0 0 S 0.0 0.0 1:50.90 ksoftirqd/4
35 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/4:0H-kblockd
36 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/5
37 root rt 0 0 0 0 S 0.0 0.0 0:07.70 migration/5
38 root 20 0 0 0 0 S 0.0 0.0 2:02.20 ksoftirqd/5
40 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/5:0H-events_highpri
41 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/6
42 root rt 0 0 0 0 S 0.0 0.0 0:07.91 migration/6
43 root 20 0 0 0 0 S 0.0 0.0 2:23.08 ksoftirqd/6
同时检查网络和时钟：
- 网络接口存在历史累计错误计数，但实时 %ifutil 很低，没有带宽打满
- 节点间时间基本一致，集群也没有 clock skew 告警
[root@HB-TJ-SDS-R4900G3-4110-001 ~]# netstat -i | column -t
Kernel Interface table
Iface MTU RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
bond0 1500 2811717022 0 0 0 2986233552 0 5 0 BMmRU
bond-storex 1500 13384925688 142004 0 142004 13874378399 0 4 0 BMmRU
bond-storex:xms 1500 - no statistics available - BMmRU
bond-storin 1500 1714539102 175702 0 175702 1715558215 0 5 0 BMmRU
docker0 1500 0 0 0 0 0 0 0 0 BMU
enp61s0f0 1500 2049841468 0 0 0 1447578205 0 0 0 BMsRU
enp61s0f1 1500 761875587 0 0 0 1538655347 0 0 0 BMsRU
enp61s0f2 1500 0 0 0 0 0 0 0 0 BMU
enp61s0f3 1500 0 0 0 0 0 0 0 0 BMU
ens1f0 1500 6416635001 85940 0 85940 7002983357 0 0 0 BMsRU
ens1f1 1500 848329555 86862 0 86862 893136906 0 0 0 BMsRU
ens2f0 1500 6968290687 56064 0 56064 6871395042 0 0 0 BMsRU
ens2f1 1500 866209547 88840 0 88840 822421309 0 0 0 BMsRU
lo 65536 4619339023 0 0 0 4619339023 0 0 0 LRU
[root@HB-TJ-SDS-R4900G3-4110-001 ~]# sar -n DEV 1 10
Linux 5.10.0-216.0.0.115.oe2203sp4.x86_64 (HB-TJ-SDS-R4900G3-4110-001) 05/07/2026 _x86_64_ (32 CPU)
03:07:16 PM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
03:07:17 PM lo 3073.00 3073.00 1692.07 1692.07 0.00 0.00 0.00 0.00
03:07:17 PM enp61s0f0 1250.00 1127.00 335.97 782.94 0.00 0.00 0.00 0.64
03:07:17 PM ens2f0 3574.00 3658.00 537.41 518.37 0.00 0.00 1.00 0.04
03:07:17 PM enp61s0f1 383.00 837.00 70.93 510.45 0.00 0.00 0.00 0.42
03:07:17 PM ens2f1 283.00 185.00 32.14 22.60 0.00 0.00 1.00 0.00
03:07:17 PM enp61s0f2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
03:07:17 PM ens1f0 3518.00 3606.00 730.21 511.23 0.00 0.00 1.00 0.06
03:07:17 PM enp61s0f3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
03:07:17 PM ens1f1 199.00 200.00 22.70 22.15 0.00 0.00 1.00 0.00
03:07:17 PM bond-storin 482.00 385.00 54.84 44.75 0.00 0.00 2.00 0.00
03:07:17 PM bond0 1633.00 1964.00 406.90 1293.39 0.00 0.00 0.00 0.53
03:07:17 PM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
03:07:17 PM bond-storex 7092.00 7264.00 1267.62 1029.60 0.00 0.00 2.00 0.05
03:07:17 PM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s %ifutil
03:07:18 PM lo 2266.00 2266.00 733.14 733.14 0.00 0.00 0.00 0.00
03:07:18 PM enp61s0f0 1802.00 1192.00 408.43 289.30 0.00 0.00 1.00 0.33
03:07:18 PM ens2f0 3637.00 3676.00 653.04 531.85 0.00 0.00 1.00 0.05
03:07:18 PM enp61s0f1 772.00 1325.00 178.68 305.85 0.00 0.00 1.00 0.25
03:07:18 PM ens2f1 421.00 327.00 54.54 45.38 0.00 0.00 1.00 0.00
03:07:18 PM enp61s0f2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
03:07:18 PM ens1f0 3696.00 3662.00 1306.93 516.54 0.00 0.00 1.00 0.11
03:07:18 PM enp61s0f3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
03:07:18 PM ens1f1 220.00 438.00 40.13 58.01 0.00 0.00 1.00 0.00
03:07:18 PM bond-storin 641.00 765.00 94.67 103.39 0.00 0.00 2.00 0.00
03:07:18 PM bond0 2574.00 2517.00 587.10 595.15 0.00 0.00 2.00 0.24
03:07:18 PM docker0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
03:07:18 PM bond-storex 7333.00 7338.00 1959.97 1048.39 0.00 0.00 2.00 0.08
[root@HB-TJ-SDS-R4900G3-4110-001 ~]# for i in `grep 10.102.43 /etc/hosts | awk '{print $1}'`
> do
> ssh $i "date"
> done
Authorized users only. All activities may be monitored and reported.
Thu May 7 03:08:29 PM CST 2026
Authorized users only. All activities may be monitored and reported.
Thu May 7 03:08:29 PM CST 2026
Authorized users only. All activities may be monitored and reported.
Thu May 7 03:08:29 PM CST 2026
Authorized users only. All activities may be monitored and reported.
Thu May 7 03:08:29 PM CST 2026
Authorized users only. All activities may be monitored and reported.
Thu May 7 03:08:29 PM CST 2026
Authorized users only. All activities may be monitored and reported.
Thu May 7 03:08:30 PM CST 2026
这一步排除了最常见的“节点资源不足”和“网络/时钟异常”因素，说明问题应继续下沉到底层介质。
3. 检查设备布局和缓存策略
查看设备映射后发现，异常 OSD 的 block 和 db_wal 并没有部署在独立的 SSD/NVMe 上，而是共享同一块机械盘的不同分区：
- block -> sdc2
- db_wal -> sdc3
- OSD 目录挂载在 sdc1
[root@HB-TJ-SDS-R4900G3-4110-001 ~]# lsblk -o NAME,TYPE,SIZE,MODEL,MOUNTPOINT
NAME TYPE SIZE MODEL MOUNTPOINT
sdc disk 7.3T ST8000NC0002-1XX112
├─sdc1 part 20G /var/lib/ceph/osd/ceph-41
├─sdc2 part 7.3T
└─sdc3 part 3G
[root@HB-TJ-SDS-R4900G3-4110-001 ~]# ll /var/lib/ceph/osd/ceph-41
total 48
-rw-r--r-- 1 root root 582 Apr 15 10:16 activate.monmap
-rw-r--r-- 1 root root 3 Apr 15 10:18 active
lrwxrwxrwx 1 root root 58 Apr 15 10:15 block -> /dev/disk/by-partuuid/c8c08e10-6204-425e-8c7b-2f51e58f575f
-rw-r--r-- 1 root root 37 Apr 15 10:15 block_uuid
-rw-r--r-- 1 root root 37 Apr 15 10:15 ceph_fsid
drwxr-xr-x 2 root ceph 206 May 7 09:26 db
lrwxrwxrwx 1 root root 58 Apr 15 10:15 db_wal -> /dev/disk/by-partuuid/37fc1ba7-478b-4bb9-a7c1-55f8de1d008f
-rw-r--r-- 1 root root 37 Apr 15 10:15 fsid
-rw-r--r-- 1 root ceph 4 Apr 15 10:16 journal_done
-rw-r--r-- 1 root ceph 8 Apr 15 10:16 kv_backend
-rw-r--r-- 1 root root 21 Apr 15 10:15 magic
-rw-r--r-- 1 root ceph 4 Apr 15 10:16 mkfs_done
-rw-r--r-- 1 root ceph 6 Apr 15 10:17 ready
-rw-r--r-- 1 root root 0 Apr 16 13:33 systemd
-rw-r--r-- 1 root root 8 Apr 15 10:15 type
-rw-r--r-- 1 root root 3 Apr 15 10:16 whoami
[root@HB-TJ-SDS-R4900G3-4110-001 ~]# ll /dev/disk/by-partuuid/c8c08e10-6204-425e-8c7b-2f51e58f575f
lrwxrwxrwx 1 root root 10 Apr 23 17:07 /dev/disk/by-partuuid/c8c08e10-6204-425e-8c7b-2f51e58f575f -> ../../sdc2
[root@HB-TJ-SDS-R4900G3-4110-001 ~]# ll /dev/disk/by-partuuid/37fc1ba7-478b-4bb9-a7c1-55f8de1d008f
lrwxrwxrwx 1 root root 10 Apr 23 17:07 /dev/disk/by-partuuid/37fc1ba7-478b-4bb9-a7c1-55f8de1d008f -> ../../sdc3
也就是说，这个 OSD 的数据面和 db/wal 路径最终都要经过同一块机械盘完成写确认。
进一步检查缓存策略后又发现：
- 硬盘自身写缓存关闭
- 原始部署方式是直通盘，不经过 RAID 逻辑卷
- 也就无法利用 RAID 卡写缓存能力
[root@HB-TJ-SDS-R4900G3-4110-001 ~]# hdparm -W /dev/sdc
/dev/sdc:
write-caching = 0 (off)
[root@HB-TJ-SDS-R4900G3-4110-001 ~]# smartctl -g wcache /dev/sdc
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.10.0-216.0.0.115.oe2203sp4.x86_64] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org
Write cache is: Disabled
到这里，问题已经开始收敛：
在机械盘直通、硬盘写缓存关闭的前提下，BlueStore 的小块同步写很可能直接走到了较慢的机械写确认路径。
4. 低负载下观察磁盘时延
为了确认问题是否由磁盘压力过大引起，对异常盘 sdc 及其分区做了实时观测。
结果比较有意思：
在观测窗口内，整盘写入负载非常低，大约只有：
- 3 w/s
- 16 KiB/s
- %util 仅 3%~5%
- aqu-sz 很低
但与此同时：
- 整盘 w_await 仍在 13~19ms
- db_wal 所在分区 sdc3 的 w_await 稳定在 13~20ms
[root@HB-TJ-SDS-R4900G3-4110-001 ~]# iostat -dx 1 sdc sdc1 sdc2 sdc3
Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s wrqm/s %wrqm w_await wareq-sz d/s dkB/s drqm/s %drqm d_await dareq-sz f/s f_await aqu-sz %util
sdc 0.00 0.00 0.00 0.00 0.00 0.00 3.00 16.00 0.00 0.00 13.33 5.33 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.04 4.00
sdc1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdc2 0.00 0.00 0.00 0.00 0.00 0.00 1.00 4.00 0.00 0.00 5.00 4.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.01 0.50
sdc3 0.00 0.00 0.00 0.00 0.00 0.00 2.00 12.00 0.00 0.00 17.50 6.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.04 3.50
这说明问题并不是“磁盘被打满后产生排队”，而是在很低的 IOPS 和带宽下，单次写请求本身的完成等待时间就偏高。
换句话说，本次问题的关键矛盾不是“盘忙”，而是“写确认慢”。
5. 用 blktrace 确认延迟位置
为了进一步确认延迟发生在块层排队还是设备完成阶段，我对异常盘 /dev/sdc 执行了 blktrace。
[root@HB-TJ-SDS-R4900G3-4110-001 ~]# blktrace -d /dev/sdc -o - | blkparse -i -
8,32 2 1 0.000000000 1911750 A WFS 45256520 + 16 <- (8,35) 3311432
8,32 2 2 0.000001263 1911750 Q WS 45256520 + 16 [journal_write]
8,32 2 3 0.000005057 1911750 G WS 45256520 + 16 [journal_write]
8,32 2 4 0.000012877 1911750 P N [journal_write]
8,32 2 5 0.000013400 1911750 U N [journal_write] 1
8,32 2 6 0.000013853 1911750 I WS 45256520 + 16 [journal_write]
8,32 2 7 0.000018323 1911750 D WS 45256520 + 16 [journal_write]
8,32 23 1 0.033183122 0 C WS 45256520 + 16 [0]
8,32 2 17 1.001998287 1911750 A WFS 45256544 + 16 <- (8,35) 3311456
8,32 2 18 1.001999178 1911750 Q WS 45256544 + 16 [journal_write]
8,32 2 19 1.002002091 1911750 G WS 45256544 + 16 [journal_write]
8,32 2 20 1.002008543 1911750 P N [journal_write]
8,32 2 21 1.002009278 1911750 U N [journal_write] 1
8,32 2 22 1.002009766 1911750 I WS 45256544 + 16 [journal_write]
8,32 2 23 1.002013855 1911750 D WS 45256544 + 16 [journal_write]
8,32 6 1 1.041402603 0 C WS 45256544 + 16 [0]
抓取结果显示：
- 整体负载依然很低，只有少量小块写请求
- journal_write 的 A/Q/G/P/U/I/D 过程基本都在微秒级完成
- 但从 D（dispatch）到 C（complete）却常常需要 28~39ms
- 也有部分请求在 8ms 左右完成
也就是说，请求在块层排队和下发都很快，真正慢的是“请求已经下发到设备后，到设备完成返回之前”这一段。
这一步进一步说明：
- 当前磁盘负载很低，不存在高并发排队问题
- 延迟主要发生在设备完成阶段
- 慢写的主要来源正是 journal_write，也就是 BlueStore db/wal 路径上的小块同步写
三、改造验证
为了验证问题是否确实与底层写确认路径有关，后续将异常盘由直通盘改造成单盘 RAID0，并打开 RAID 卡读写缓存。
改造前：
- 盘为直通盘
- 硬盘自身写缓存关闭
- 无 RAID 控制器缓存参与
改造后：
- 同一块物理盘被创建为控制器逻辑卷
- 读缓存开启
- 写缓存状态为 On when protected by battery/ZMM（如果没有超级电容/电池保护，RAID 卡就不允许自己开写缓存；如果有保护，就允许开）
[root@HB-TJ-SDS-R4900G3-4110-001 ~]# lsscsi
[0:1:9:0] disk ATA ST8000NC0002-1XX CN02 /dev/sdc
[root@HB-TJ-SDS-R4900G3-4110-001 ~]# /opt/sds/diskled/arcconf list 1
Physical 0,9 : Raw (Pass Through) (SATA, 512 Bytes, 7630885MB, ATA, ST8000NC0002-1XX, Hard Drive) 5000C500B03A16F2, [Enclosure 0, Slot 1(Connector 0, Connector 1)]
[root@HB-TJ-SDS-R4900G3-4110-001 ~]# /opt/sds/diskled/arcconf task start 1 device 0 9 initialize
[root@HB-TJ-SDS-R4900G3-4110-001 ~]# /opt/sds/diskled/arcconf CREATE 1 LOGICALDRIVE MAX SIMPlE_VOLUME 0 9
[root@HB-TJ-SDS-R4900G3-4110-001 ~]# /opt/sds/diskled/arcconf list 1
Physical 0,9 : Online (SATA, 512 Bytes, 7630885MB, ATA, ST8000NC0002-1XX, Hard
[root@HB-TJ-SDS-R4900G3-4110-001 ~]# /opt/sds/diskled/arcconf getconfig 1 ld
[root@HB-TJ-SDS-R4900G3-4110-001 ~]# /opt/sds/diskled/arcconf setcache 1 logicaldrive 1 wbb
需要说明的是，改造后系统识别出的盘符由原先的 sdc 变为 sdp，但它对应的仍然是同一块物理盘改造后的逻辑设备，并不是更换了新的存储介质。
改造完成后，再次观察：
[root@HB-TJ-SDS-R4900G3-4110-001 ~]# iostat -dx 1 sdp sdp1 sdp2 sdp3
Device r/s rkB/s rrqm/s %rrqm r_await rareq-sz w/s wkB/s wrqm/s %wrqm w_await wareq-sz d/s dkB/s drqm/s %drqm d_await dareq-sz f/s f_await aqu-sz %util
sdp 0.00 0.00 0.00 0.00 0.00 0.00 3.00 16.00 0.00 0.00 0.00 5.33 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdp1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdp2 0.00 0.00 0.00 0.00 0.00 0.00 1.00 4.00 0.00 0.00 0.00 4.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
sdp3 0.00 0.00 0.00 0.00 0.00 0.00 2.00 12.00 0.00 0.00 0.00 6.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
结果显示，在与改造前相同量级的低负载场景下：
- 整盘 sdp 仍只有约 3 w/s、16 KiB/s
- 整盘 w_await 基本降至 0~1ms
- block 分区 sdp2 的 w_await 降至 0~1ms
- db_wal 分区 sdp3 的 w_await 基本接近 0ms
也就是说，负载没变，但单次小块写确认时延被大幅压缩了。
这一步验证了两个关键判断：
- 问题根因并不在 Ceph 软件栈，也不是业务压力过大导致的排队
- 当前瓶颈确实集中在底层机械盘直接承接 BlueStore db/wal 小块同步写时的写确认能力上
从结果上看，单盘 RAID0 并没有改变机械盘介质本身，而是通过控制器缓存优化了写入完成路径，从而显著降低了 OSD commit/apply latency。
四、根因结论
存储性能问题不一定意味着“硬件坏了”或“软件有 Bug”，很多时候是“业务模型、存储架构和底层介质特性没有对齐”。
对于 Ceph BlueStore 这类对 db/wal 小块同步写非常敏感的架构来说，如果底层介质既没有合适的缓存策略，又需要直接完成写确认，那么即使业务负载很低，也可能持续表现出较高时延。
而一旦通过更合适的缓存路径对写确认过程进行优化，时延往往就会出现明显改善。
因此，这次问题更准确的定义应该是：
机械盘直通部署方式下，小块同步写确认路径过慢导致的 OSD 高时延问题。
AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。
更多推荐
13
0- 0
已为社区贡献2条内容
所有评论(0)