K8S 容器环境下 Disk I/O 性能调优

某云原生应用在部署阶段对磁盘 I/O 有明确要求：在挂载的 volume 上执行 dd 测试时，写入速度必须 ≥ 1MB/s。初始测试结果只有 500~600 KB/s，排查了一圈才发现，瓶颈不在磁盘本身，而在网络延时。

背景与测试命令

在挂载的 volume 上执行：

dd if=/dev/zero of=./test2.img bs=4k count=10240 oflag=direct

测试特点：

• 顺序写
• 使用 O_DIRECT（无 page cache）
• 无 fsync、无元数据更新、无 WAL / journal
• 无随机写、无多层 flush

这是一个 4K 小块、无缓存、直写磁盘的场景。如果在此条件下仍能满足性能要求，基本可以覆盖关系型数据库的所有严苛 I/O 场景。

系统架构与部署环境

1. 3 台 Baremetal（HP DL380 Gen11）

   • CPU：96 Core × 4
   • 内存：512 GB
   • 磁盘：4 × 4T HDD + 4 × 4T SSD
   • 网络：10G 光口

2. HDD 做 RAID1 用于 Host OS，SSD 不做 RAID

3. Host OS：Ubuntu 24.04，启用 KVM

4. 每台 Host 上运行多个 VM，其中部分 VM 挂载 SSD

5. VM 上部署 OpenShift

6. 3 个挂载 SSD 的 VM 作为存储节点，部署 ODF（Ceph）

   • 每块 SSD 对应一个 Ceph OSD

7. OpenShift 内部署 MariaDB 集群

   • 1 Master + 2 Slave
   • 使用 Ceph RWO Volume

8. 在 MariaDB 数据卷中执行 I/O 测试

调优过程

初始测试结果约 500~600 KB/s，远低于目标。

• Host 与 VM 层磁盘性能正常（SSD >100MB/s）
• VM 磁盘使用 virtio + cache=none + io=native

<disk type='block' device='disk'>
  <driver name='qemu' type='raw' cache='none' io='native' iothreads='8'/>
  <source dev='/dev/nvme0n1'/>
  <target dev='sda' bus='virtio'/>
  <address type='pci' controller='0' bus='0' target='0' unit='0'/>
</disk>

徘徊多次后仍旧提升非常有限。检查 Ceph 性能指标时发现：

root@service:~# oc exec $(oc get pod -n openshift-storage | grep tools | head -n 1) -n openshift-storage -it -- bash
bash-5.1$ ceph osd perf
osd commit_latency(ms) apply_latency(ms)
11                   0                 0
10                   0                 0
 9                   0                 0
 8                   0                 0
 7                   0                 0
 6                   0                 0
 5                   4                 4
 4                   0                 0
 3                   0                 0
 2                   4                 4
 1                   2                 2
 0                   5                 5

OSD 网络延时有问题——不在同一个 host 上的 OSD 延时明显较大。对比参考环境，OSD 之间的延时应低于 1ms。

进一步验证网络延时，VM 和 VM 之间、甚至 HOST 之间的 ping 值也高于 1ms，基本锁定：性能上不去是网络延时引起的，而不是 disk I/O 本身。

为了进一步验证，把 Ceph 的副本个数从三个改成一个，测试结果有了明显提升。

错误的尝试

• SR-IOV：把 HOST 的网卡开启 SR-IOV，网络延时瞬间降到 0.1ms，提升明显，但部署 OCP 过程遇到很多问题；考虑到 NUMA 的影响，资源会浪费一半，无法走通，遂放弃。
• MTU：从 1500 增加到 8500，有提升到 700 KB/s，仍无法满足要求，而且 OCP 更改 MTU 的成本也挺高。

核心瓶颈

和另外一套 lab 环境对比后，发现几处不同：我们的网卡是英特尔 + 10G 光口，另一套 lab 是高通 + 10G 电口，ping 值差距明显（1ms vs 0.1ms）。怀疑网卡配置，调试多次、甚至交换网卡后仍无明显改变。

最后猜测是不是 CPU 调度问题。两个 OS 分别是 Ubuntu 和 RedHat。查询后发现 Ubuntu 在很久前就引入了 CPU idle（C-states），默认启用 cpuidle 子系统，允许 CPU 进入多级低功耗状态。Ubuntu 24.04 还引入并默认使用 power-profiles-daemon 统一管理电源策略：

• 桌面环境提供电源模式（Balanced / Power-Saver / Performance）
• 默认是 Balanced 模式，结合 P-states + idle states 使功耗更低

参考：https://help.ubuntu.com/stable/ubuntu-help/power-profile.html.en

检查 Host OS 后，果然是默认开启了这个配置。修改成 Performance 模式，网速 ping 值提升到 0.1ms，Ceph 的性能延时也降到 1ms 内。

再次测试 dd，效果立竿见影达到 1.4M/s，达成目标。

总结

1. 确认问题是网络延时引起的，明确瓶颈方向后持续深挖，避免无效调参。
2. Host OS 尽量使用成熟的商业版本，推荐 RedHat / RockyLinux。
3. 上层有软件级别的存储服务（Ceph），物理层就不要做 RAID 了。
4. KVM 跨 node 部署时还是会有小问题，优先还是安装 OpenStack 作为 VNF 层。

注意：以下命令会直接破坏磁盘数据，注意 of 的指向目录，请勿在生产环境使用：

dd if=/dev/zero of=/dev/vdd bs=4k count=10240 oflag=direct