Akemi

FIO工具与存储诊断思路

2025/05/27

测试存储系统需要模拟真实的工作负载。fio命令使用多个线程和进程模拟工作负载。场景包括顺序的、随机的读写和混合的I/O类型。该工具支持在单个文件上创建多线程I/O请求。

参数说明

1
2
3
4
5
6
7
8
9
10
11
12
13
14
fio --name=randwrite --ioengine=libaio --iodepth=1 \
--rw=randwrite --bs=4k --direct=1 --size=512M --numjobs=2 \
--group_reporting --filename=/tmp/testfile

--name=randwrite 自定义任务名称
--ioengine=libaio 指定I/O引擎为libaio(Linux 原生异步I/O库)
--iodepth=1 表示每个作业一次只提交1个I/O请求(无队列堆积
--rw=randwrite 测试模式为「随机写入」
--bs=4k 每次 I/O 操作的块大小为 4KB
--direct=1 直接读写磁盘,避免缓存干扰
--size=512M 每个作业写入的总数据量为 512MB
--numjobs=2 启动 2 个并发作业
--group_reporting 合并报告所有作业的结果
--filename=/tmp/testfile 指定测试文件的路径

报告解读

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
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
Starting 2 processes     # 启动 2 个并发作业(对应 numjobs=2)
randwrite: Laying out IO file (1 file / 512MiB) # 创建 512MB 测试文件
Jobs: 2 (f=2): [w(2)][100.0%][w=8475KiB/s][w=2118 IOPS][eta 00m:00s]
# 实时进度:
# - [w(2)]: 2 个写入作业运行中
# - [w=8475KiB/s]: 当前瞬时带宽
# - [w=2118 IOPS]: 当前瞬时每秒操作数
# - [eta 00m:00s]: 剩余时间(已接近完成)

randwrite: (groupid=0, jobs=2): err= 0: pid=86720: Tue May 27 10:25:52 2025
# 任务汇总:
# - groupid=0: 分组 ID
# - err=0: 无错误
# - pid=86720: 主进程 ID
# - 测试完成时间

write: IOPS=2134, BW=8539KiB/s (8744kB/s)(1024MiB/122799msec); 0 zone resets
# 最终结果:
# - IOPS=2134: 平均每秒 2134 次 4KB 写入操作
# - BW=8539KiB/s: 平均带宽(约 8.34 MiB/s)
# - 总写入量 1024MiB(2 个作业各 512MiB)
# - 总耗时 122799 毫秒(约 122.8 秒)
# - zone resets=0: ZNS 设备相关(非 ZNS 磁盘可忽略)

slat (usec): min=3, max=803, avg=12.21, stdev=18.04
# 提交延迟(slat):
# - 请求从提交到内核接受的时间(单位微秒)
# - 最小 3μs,最大 803μs,平均 12.21μs,标准差 18.04μs(分布较集中)

clat (usec): min=26, max=12910, avg=921.99, stdev=1106.03
# 完成延迟(clat):
# - 请求从提交到完成的时间(单位微秒)
# - 平均 921.99μs(约 0.92ms),但标准差大(1106μs),延迟波动明显

lat (usec): min=477, max=12916, avg=934.41, stdev=1105.46
# 总延迟(lat = slat + clat):
# - 平均 934.41μs(约 0.93ms)

clat percentiles (usec):
# 完成延迟百分位数(关键性能指标):
| 1.00th=[ 553], 5.00th=[ 553], 10.00th=[ 562], 20.00th=[ 570],
| 30.00th=[ 570], 40.00th=[ 578], 50.00th=[ 586], 60.00th=[ 594],
| 70.00th=[ 619], 80.00th=[ 693], 90.00th=[ 963], 95.00th=[ 3884],
| 99.00th=[ 6718], 99.50th=[ 7308], 99.90th=[ 8029], 99.95th=[ 8356],
| 99.99th=[ 9241]
# 解读:
# - 50% 的请求延迟 ≤ 586μs(约 0.59ms,性能优秀)
# - 但 95% 的请求延迟 ≤ 3884μs(约 3.88ms,存在长尾延迟)
# - 最差 0.01% 请求延迟达 9241μs(约 9.24ms,可能是磁盘负载过高或硬件瓶颈)

bw ( KiB/s): min= 8024, max=12483, per=100.00%, avg=8546.52, stdev=253.75, samples=488
# 带宽统计:
# - 最小 8024 KiB/s,最大 12483 KiB/s
# - 平均 8546.52 KiB/s(约 8.35 MiB/s)
# - 标准差 253.75(带宽波动较小)

iops: min=2006, max=3120, avg=2136.59, stdev=63.42, samples=488
# IOPS统计:
# - 瞬时 IOPS 波动在 2006~3120 之间
# - 平均 2136.59,接近最终报告的 2134

lat (usec)分布:
lat (usec) : 50=0.01%, 100=0.01%, 250=0.01%, 500=0.01%, 750=83.68%
lat (usec) : 1000=6.66%
lat (msec) : 2=1.83%, 4=3.56%, 10=4.27%, 20=0.01%
# 延迟分布详情:
# - 83.68% 的请求延迟 ≤ 750μs
# - 6.66% 在 750μs~1ms
# - 4.27% 在 2ms~10ms(可能与磁盘负载高峰相关)

cpu: usr=0.56%, sys=1.48%, ctx=264771, majf=0, minf=23
# CPU使用:
# - usr=0.56%: 用户态CPU占用(极低)
# - sys=1.48%: 内核态CPU占用(低,说明测试未受CPU限制)
# - ctx=264771: 上下文切换次数(较高,因并发作业)
# - majf=0: 主要缺页错误(无)
# - minf=23: 次要缺页错误(正常)

IO depths: 1=100.0%
# I/O队列深度分布:
# - 100% 的请求在队列深度1(符合 --iodepth=1 的设置)

submit/completion统计:
submit : 0=0.0%, 4=100.0% # 100% 的 I/O 通过每次提交4个请求完成(libaio特性)
complete : 0=0.0%, 4=100.0% # 100% 的 I/O 完成时返回4个请求
issued rwts: total=0,262144,0,0 # 总计 262144 次写入(262144 x 4KB = 1024MiB)

latency目标:
latency target=0(未设置延迟限制)

Run status group 0:
WRITE: bw=8539KiB/s, io=1024MiB, run=122799msec
# 最终汇总:
# - 总带宽 8539KiB/s,总数据量1024MiB,耗时约122.8秒

Disk stats (read/write):
vda: ios=67/262049, merge=0/2, ticks=96/237006, in_queue=237103, util=99.95%
# 磁盘vda统计:
# - ios=67/262049: 读67次,写262049次(符合测试模式)
# - merge=0/2: 合并的读请求0次,写请求2次(几乎无合并)
# - in_queue=237103ms: 总排队时间
# - util=99.95%: 磁盘利用率接近100%(磁盘已成为瓶颈!)

诊断存储IO思路

通常,存储问题是在应用程序级别检测到的,执行时间非常长

应用程序可能正在使用SAN或NAS设备或系统,其响应时间可能看起来正常

top命令

%Cpu(s): 0.0 us, 0.0 sy, 0.0 ni, 99.9 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st

在CPU使用率这一行,如果us(cpu使用)低而wa(cpu等待)高,表明可能存在IO瓶颈

iostat工具

使用iostat -x

查看各设备的%util信息,反应了设备利用率,如果非常高,超过100%可能就有问题

iotop工具

将进程阻塞与对于的进程联系起来

1
2
3
4
5
Total DISK READ :       0.00 B/s | Total DISK WRITE :       8.33 M/s
Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 8.33 M/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
87329 be/4 root 0.00 B/s 4.15 M/s 0.00 % 0.00 % fio --name=randwri~1 --group_reporting
87330 be/4 root 0.00 B/s 4.17 M/s 0.00 % 0.00 % fio --name=randwri~1 --group_reporting

blktrace工具

识别特定设备的IO操作信息

1
2
3
4
5
6
blktrace -d /dev/vda3
^=== vda3 ===
CPU 0: 4 events, 1 KiB data
CPU 1: 34 events, 2 KiB data
Total: 38 events (dropped 0), 2 KiB data

PCP工具集

1
2
3
4
5
6
7
8
9
yum -y install pcp-system-tools
systemctl enable pmcd.service --now

pmiostat
# Device rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await %util
vda 0.00 0.00 0.00 2115.62 0.00 8462.47 4.000 63.662 30.09 0.00 30.09 99.99
vda 0.00 0.00 2.00 2120.90 19.96 8483.60 4.006 63.662 29.99 32.00 29.99 99.41
vda 0.00 0.00 0.00 2115.46 0.00 8461.83 4.000 63.693 30.11 0.00 30.11 100.03

原文作者:王盛

原文链接:https://akemi.zj.cn/2025/05/27/Linux-FIO/

发表日期:May 27th 2025, 5:30:14 pm

更新日期:May 27th 2025, 5:30:42 pm

版权声明:本文采用知识共享署名-非商业性使用 4.0 国际许可协议进行许可

CATALOG
  1. 1. 参数说明
  2. 2. 报告解读
  3. 3. 诊断存储IO思路