基于华为云 FlexusX 四节点集群的云计算全栈实操三云硬盘 IO 压测fio 全场景读懂 IOPS 与吞吐前两篇我们搭好了实验室、给 CPU/内存做了体检。本篇把目光投向最容易「翻车」的 storage云硬盘的 IOPS 和吞吐到底是多少为什么数据库和对象存储对云盘的要求天差地别我们用 fio 跑五个场景把数字扒开。0. 引子云上最容易被低估的瓶颈很多性能问题最后都落在磁盘上。应用层调得再好如果云盘 IOPS 不够、尾延迟爆炸MySQL 的慢查询、Kafka 的刷盘停顿、容器镜像的拉取都会跟着抖。问题是——云盘的性能是「分场景」的顺序大块读写看吞吐MiB/s随机小块读写看 IOPS。买错类型钱花三倍体验还差。《深入浅出云计算》把存储分为「块存储 / 对象存储 / 文件存储」。本篇聚焦最底层的块存储云硬盘用 fio 量化它的能力边界并给出选型与成本权衡。1. 理论先分清几个容易混的概念IOPSInput/Output Operations Per Second每秒能完成多少次 IO。小块如 4KiB随机读写时IOPS 是天花板。吞吐ThroughputMiB/s每秒搬多少数据。大块如 1MiB顺序读写时吞吐是天花板。二者的关系吞吐 ≈ IOPS × 块大小。4KiB 随机读 8000 IOPS ≈ 31 MiB/s1MiB 顺序读 120 IOPS ≈ 120 MiB/s。块越大相同 IOPS 下吞吐越高。iodepth单个进程的「在途 IO 深度」。云盘后端是队列iodepth 太小喂不饱太大则排队延迟上升。numjobs并发进程数。多进程 适当 iodepth才能压出云盘标称峰值。一句话小块看 IOPS大块看吞吐要压满得靠 iodepth × numjobs 把队列喂饱。2. 实验环境四节点规格同上篇8vCPU/16GiBUbuntu 24.04.4 LTS。本次被测盘为各节点的40G 系统盘/dev/vda注意是系统盘非独立数据盘性能口径需结合这一点看。压测在 node1、node3 两个节点采样。 云硬盘信息 NAME SIZE ROTA SCHED vda 40G 1 noneROTA1是 lsblk 对 virtio 块设备的常规标记不代表真机械盘SCHEDnone说明使用了无队列调度的 virtio 路径。3. 实操fio_bench.sh 五个场景我用scripts/fio_bench.sh一次性跑完五个场景--direct1绕过页缓存、测真实盘libaio异步引擎time_basedruntime20取稳态。关键参数如下# 顺序写1M 大块iodepth32fio--nameseqwrite--directory/root/fiotest--ioenginelibaio--direct1--rwwrite\--bs1M--iodepth32--numjobs1--size2G--runtime20--time_based--group_reporting# 顺序读1M 大块iodepth32fio--nameseqread--directory/root/fiotest--ioenginelibaio--direct1--rwread\--bs1M--iodepth32--numjobs1--size2G--runtime20--time_based--group_reporting# 随机写4k 小块iodepth644 进程fio--namerandwrite--directory/root/fiotest--ioenginelibaio--direct1--rwrandwrite\--bs4k--iodepth64--numjobs4--size512M--runtime20--time_based--group_reporting# 随机读4k 小块iodepth644 进程fio--namerandread--directory/root/fiotest--ioenginelibaio--direct1--rwrandread\--bs4k--iodepth64--numjobs4--size512M--runtime20--time_based--group_reporting# 混合读写 70/30读占 70%fio--namerandrw--directory/root/fiotest--ioenginelibaio--direct1--rwrandrw--rwmixread70\--bs4k--iodepth64--numjobs4--size512M--runtime20--time_based--group_reporting并行下发PYTHONPATHdeps python tools/fanout.py n1,n3bash /root/fio_bench.sh4. 真实输出来自 results/03_fio_bench.txtnode1 (113.47.6.41) [1] 顺序写 bs1M iodepth32 write: IOPS125, BW126MiB/s (132MB/s)(2550MiB/20298msec) [2] 顺序读 bs1M iodepth32 read: IOPS117, BW118MiB/s (123MB/s)(2432MiB/20672msec) [3] 随机写 bs4k iodepth64 numjobs4 write: IOPS8152, BW31.8MiB/s (33.4MB/s)(653MiB/20508msec) clat percentiles (usec): | 99.00th[ 968885] [4] 随机读 bs4k iodepth64 numjobs4 read: IOPS8094, BW31.6MiB/s (33.2MB/s)(657MiB/20782msec) clat percentiles (usec): | 99.00th[ 977273] [5] 混合读写 70/30 bs4k read: IOPS5655, BW22.1MiB/s (23.2MB/s)(459MiB/20787msec) write: IOPS2437, BW9750KiB/s (9984kB/s)(198MiB/20787msec)node3 (1.94.220.182) [1] 顺序写 bs1M iodepth32 write: IOPS126, BW127MiB/s (133MB/s)(2551MiB/20141msec) [2] 顺序读 bs1M iodepth32 read: IOPS120, BW121MiB/s (126MB/s)(2473MiB/20500msec) [3] 随机写 bs4k iodepth64 numjobs4 write: IOPS8071, BW31.5MiB/s (33.1MB/s)(653MiB/20700msec) clat percentiles (usec): | 99.00th[ 968885] [4] 随机读 bs4k iodepth64 numjobs4 read: IOPS8089, BW31.6MiB/s (33.1MB/s)(657MiB/20791msec) clat percentiles (usec): | 99.00th[ 977273] [5] 混合读写 70/30 bs4k read: IOPS5651, BW22.1MiB/s (23.1MB/s)(459MiB/20788msec) write: IOPS2437, BW9748KiB/s (9982kB/s)(198MiB/20788msec)汇总对比场景指标node1node3顺序写 (1M)吞吐126 MiB/s (125 IOPS)127 MiB/s (126 IOPS)顺序读 (1M)吞吐118 MiB/s (117 IOPS)121 MiB/s (120 IOPS)随机写 (4k)IOPS / 吞吐8152 / 31.8 MiB/s8071 / 31.5 MiB/s随机读 (4k)IOPS / 吞吐8094 / 31.6 MiB/s8089 / 31.6 MiB/s混合 70/30 (4k)读 IOPS / 写 IOPS5655 / 24375651 / 2437两节点几乎一致符合系统盘的同质预期。5. 深度解读重点5.1 吞吐 vs IOPS同一块盘的两个面看这张表最直观的结论大块顺序场景吞吐约 120 MiB/s、IOPS 只有 ~120小块随机场景IOPS 冲到 ~8000、吞吐却只有 ~31 MiB/s。同一个盘换了块大小天花板指标就从「吞吐」切换成「IOPS」。验证公式吞吐 IOPS × 块大小随机读 8094 IOPS × 4KiB ≈ 31.6 MiB/s ✓顺序读 120 IOPS × 1MiB ≈ 120 MiB/s ✓。两张面孔本质是一回事——盘后端的「并发能力」与「单请求搬运量」的乘积。5.2 为什么顺序读略低于顺序写这里反直觉一般企业云盘是「写有缓存/写合并、读要落盘」所以写快于读本环境顺序写 126 MiB/s、顺序读 118–121 MiB/s读略低于写。这是 40G 系统盘的限速画像——系统盘的定位就是「装系统和偶尔读」顺序读带宽被刻意压在比写更低的档位。规格选型时若需要高顺序读如训练数据集加载应换高吞吐型/SSD 数据盘。5.3 iodepth 与 numjobs为什么大块用 iodepth、小块用 iodepth×numjobs顺序 1M 场景numjobs1, iodepth32。单个大块请求本身就很「重」一个进程靠 iodepth32 把队列喂满就够了再多加进程收益不大。随机 4k 场景numjobs4, iodepth64。4KiB 请求极轻单进程即使 iodepth64 也可能喂不饱后端请求处理太快、队列空窗。用 4 个进程 × 64 深度 256 条在途 IO才把 IOPS 压到 ~8000 的天花板。经验大块看单进程 iodepth小块看 进程数×iodepth。压随机小 IO 时只调 iodepth 不调 numjobs很容易测出一个「假低点」然后误判云盘不行。5.4 尾延迟clat 99th被忽略的雷随机写的clat 99th 968885 usec≈ 969 ms随机读99th 977273 usec≈ 977 ms。这是 99 分位的完成延迟接近 1 秒。均值很漂亮4KiB 随机 ~8000 IOPS平均延迟约 0.8ms但尾部会蹿到近 1 秒。这说明这块 40G 系统盘在压力下的长尾延迟极不稳定。对延迟敏感的在线服务数据库事务提交、KV 读p99 可能会很难看。根因通常是共享存储后端在队列拥塞时的调度——这也是「系统盘」不适合扛核心数据库的根本原因之一。5.5 混合 70/30 的意义真实业务极少是纯读或纯写。混合 70/30 下读 5655 IOPS、写 2437 IOPS。注意读 IOPS 从纯随机读的 8094 掉到 5655——因为读写互相争用同一个 IO 队列和盘带宽叠加写放大效应整体吞吐被写拖慢。这提醒我们压测别只跑纯读/纯写混合比例才接近生产。6. 数据库 / 日志 / 大文件云盘选型与成本权衡基于上面的画像给三类典型负载的选型建议负载类型关键指标应选云盘成本权衡数据库MySQL/PG随机 4k IOPS、低尾延迟高 IOPS SSD 云盘如超高 IO 型并用独立数据盘而非系统盘贵但 IOPS/尾延迟直接决定 QPS 与 p99系统盘跑 DB 是禁忌。日志 / Kafka / 写放大型顺序写吞吐 一定 IOPS高吞吐型或通用 SSD顺序写本盘 ~126 MiB/s 可用量极大时按吞吐计费更划算。大文件 / 镜像 / 训练集顺序读吞吐高吞吐型 大块读顺序读 ~120 MiB/s 偏弱需高吞吐盘或并行多盘条带。成本观点云盘选型的第一原则是让「负载的瓶颈指标」匹配「云盘的峰值指标」。随机小 IO 的库别买吞吐盘花钱买用不上的 MiB/s大文件服务别买 IOPS 盘花钱买用不上的 IOPS。另外系统盘本环境的 40G vda只该装系统——任何有性能要求的存储都请挂独立数据盘。本次 8000 IOPS 的「好看数字」背后是近 1 秒的尾延迟绝不适合直接扛核心数据库。5.6 一个常见误判拿系统盘当数据盘本环境 40G vda 是系统盘它有明确的「装系统」定位顺序读被压在 ~120 MiB/s、随机 IO 尾延迟近 1 秒。很多新手把数据库 data 目录直接放在系统盘结果 QPS 上不去、偶尔卡顿查不出原因——根子就在这块盘的画像上。正确做法永远是系统归系统数据挂独立云盘按需选高 IOPS / 高吞吐型并把 IOPS 和吞吐的「突发基准」额度算进容量规划。7. 踩坑与排障--direct1一定要开不开会走页缓存测出的是内存带宽不是盘速数字虚高。不要在系统盘根分区直接写脚本用/root/fiotest临时目录并最终rm -rf避免污染与占满。iodepth 过大导致延迟飙升本文 64 已偏高若再加大IOPS 不涨、clat 反而更差说明已到后端队列极限。多节点采样差异本次仅 n1/n3 采样即高度一致正式选型建议覆盖更多节点取中值排除偶发邻居干扰。8. 配套脚本../scripts/fio_bench.sh本篇五个场景的完整 fio 脚本可直接fanout下发。../tools/ssh_run.py、../tools/fanout.py结果采集与并行下发。9. 小结本篇用 fio 把 40G 系统盘的真实成色扒开三条核心结论吞吐与 IOPS 是同一盘的两个面顺序 1M 约 120 MiB/s~120 IOPS随机 4k 约 8000 IOPS~31 MiB/s公式吞吐IOPS×块大小完全吻合压随机小 IO 必须用numjobs×iodepth单调 iodepth 会测出假低点本环境 4 进程×64 深度才压出 ~8000 IOPS尾延迟是隐藏雷随机 IO 的 99th clat 接近 1 秒系统盘绝不适合扛核心数据库——按负载瓶颈指标选独立数据盘才是正解。IaaS 三篇到此收官开篇基建、CPU/内存、云硬盘。下个阶段我们将进入PaaS 层对象存储、负载均衡、RDS vs 自建把「计算 存储」真正用成服务。