尧图网络 高端网站定制 · 原创设计
免费咨询热线
400-888-6620
免费获取方案
测试硬盘的瑞士军刀-fio
FIO (Flexible I/O Tester) 是一个用于磁盘I/O性能测试的强大工具。它的参数众多我们不可能也没必要完全记住。下面通过一个具体的命令演示。通过这个具体的例子希望能帮助你对fio有所了解。下面命令模拟数据库服务对硬盘的使用I/O块选择为8k读写比设置为7比3。fio完整命令fio--nameoltp-sim\--ioenginelibaio\--direct1\--bs8k\--size3G\--rwrandrw\--rwmixread70\--iodepth32\--numjobs4\--group_reporting\--runtime120\--time_based\--ramp_time30输出结果oltp-sim: (g0): rwrandrw, bs(R) 8192B-8192B, (W) 8192B-8192B, (T) 8192B-8192B, ioenginelibaio, iodepth32 ... fio-3.36 Starting 4 processes oltp-sim: Laying out IO file (1 file / 3072MiB) oltp-sim: Laying out IO file (1 file / 3072MiB) oltp-sim: Laying out IO file (1 file / 3072MiB) oltp-sim: Laying out IO file (1 file / 3072MiB) Jobs: 4 (f4): [m(4)][100.0%][r161MiB/s,w70.5MiB/s][r20.6k,w9026 IOPS][eta 00m:00s] oltp-sim: (groupid0, jobs4): err 0: pid54727: Thu Jun 25 09:23:16 2026 read: IOPS38.7k, BW302MiB/s (317MB/s)(35.4GiB/120002msec) slat (nsec): min785, max3517.1k, avg5204.50, stdev9422.74 clat (usec): min55, max201863, avg2136.30, stdev6055.59 lat (usec): min153, max201866, avg2141.50, stdev6055.62 clat percentiles (usec): | 1.00th[ 685], 5.00th[ 914], 10.00th[ 1045], 20.00th[ 1254], | 30.00th[ 1450], 40.00th[ 1696], 50.00th[ 1893], 60.00th[ 2057], | 70.00th[ 2212], 80.00th[ 2376], 90.00th[ 2638], 95.00th[ 2868], | 99.00th[ 3490], 99.50th[ 4146], 99.90th[102237], 99.95th[189793], | 99.99th[200279] bw ( KiB/s): min53589, max374230, per100.00%, avg310733.49, stdev22506.96, samples944 iops : min 6696, max46777, avg38840.01, stdev2813.37, samples944 write: IOPS16.6k, BW130MiB/s (136MB/s)(15.2GiB/120002msec); 0 zone resets slat (nsec): min913, max3425.1k, avg5941.29, stdev11093.02 clat (usec): min301, max201695, avg2711.91, stdev6906.19 lat (usec): min324, max201698, avg2717.85, stdev6906.22 clat percentiles (usec): | 1.00th[ 1106], 5.00th[ 1434], 10.00th[ 1631], 20.00th[ 1844], | 30.00th[ 2040], 40.00th[ 2180], 50.00th[ 2343], 60.00th[ 2474], | 70.00th[ 2638], 80.00th[ 2835], 90.00th[ 3130], 95.00th[ 3425], | 99.00th[ 4359], 99.50th[ 5342], 99.90th[103285], 99.95th[193987], | 99.99th[200279] bw ( KiB/s): min21968, max163208, per100.00%, avg133093.00, stdev9657.89, samples944 iops : min 2744, max20400, avg16635.00, stdev1207.25, samples944 lat (usec) : 1000.01%, 2500.01%, 5000.13%, 7501.04%, 10004.66% lat (msec) : 241.95%, 451.32%, 100.59%, 200.01%, 500.11% lat (msec) : 1000.02%, 2500.17% cpu : usr3.95%, sys10.33%, ctx2211187, majf0, minf149 IO depths : 10.0%, 20.0%, 40.0%, 80.0%, 160.0%, 32100.0%, 640.0% submit : 00.0%, 4100.0%, 80.0%, 160.0%, 320.0%, 640.0%, 640.0% complete : 00.0%, 4100.0%, 80.0%, 160.0%, 320.1%, 640.0%, 640.0% issued rwts: total4644062,1989240,0,0 short0,0,0,0 dropped0,0,0,0 latency : target0, window0, percentile100.00%, depth32 Run status group 0 (all jobs): READ: bw302MiB/s (317MB/s), 302MiB/s-302MiB/s (317MB/s-317MB/s), io35.4GiB (38.0GB), run120002-120002msec WRITE: bw130MiB/s (136MB/s), 130MiB/s-130MiB/s (136MB/s-136MB/s), io15.2GiB (16.3GB), run120002-120002msec Disk stats (read/write): sdd: ios5931652/2543396, sectors94906432/40694712, merge0/317, ticks11765239/6307868, in_queue18073398, util96.20%选项介绍参数值说明--nameoltp-sim测试任务名称表示模拟OLTP联机事务处理场景--ioenginelibaio使用Linux原生异步I/O引擎性能更高--direct1绕过操作系统缓存直接读写磁盘绕过Page Cache--bs8k块大小为8KB数据库常见page size--size3G每个job测试文件大小为3GB--rwrandrw随机读写混合模式--rwmixread7070%读30%写典型OLTP比例--iodepth32I/O队列深度32--numjobs4并发4个进程--group_reporting-汇总所有job的统计而非单独显示--runtime120测试运行120秒--time_based-基于时间运行即使完成size也继续跑满时间--ramp_time30预热30秒后才开始统计消除初始波动读取Read性能read: IOPS38.7k, BW302MiB/s (317MB/s)(35.4GiB/120002msec)指标值说明IOPS38.7k每秒读取38,700次I/O操作带宽 (BW)302 MiB/s读取吞吐量注意MiB是1024进制MB是1000进制总读取量35.4 GiB120秒内总共读取35.4GB数据延迟指标latencyslat (nsec): min785, max3517.1k, avg5204.50, stdev9422.74 clat (usec): min55, max201863, avg2136.30, stdev6055.59 lat (usec): min153, max201866, avg2141.50, stdev6055.62缩写全称单位平均值说明slatSubmission Latency纳秒5.2 μsI/O提交延迟fio将I/O请求提交给内核的时间clatCompletion Latency微秒2136 μs完成延迟I/O提交到内核到完成的时间latTotal Latency微秒2141 μs总延迟 ≈ slat clat延迟百分位数关键clat percentiles (usec): | 1.00th[ 685], 5.00th[ 914], 10.00th[ 1045], 20.00th[ 1254], | 30.00th[ 1450], 40.00th[ 1696], 50.00th[ 1893], 60.00th[ 2057], | 70.00th[ 2212], 80.00th[ 2376], 90.00th[ 2638], 95.00th[ 2868], | 99.00th[ 3490], 99.50th[ 4146], 99.90th[102237], 99.95th[189793], | 99.99th[200279]解读P50 1893 μs50%的读请求在1.89ms内完成中位数P99 3490 μs99%的读请求在3.49ms内完成P99.9 102 ms最差的0.1%请求需要超过100ms尾延迟P99.99 200 ms极端情况下有200ms延迟重要P99的尾延迟非常高100-200ms这可能是磁盘瓶颈或GC导致的对数据库性能影响很大。带宽和IOPS分布bw (KiB/s): min53589, max374230, avg310733.49, stdev22506.96 iops: min6696, max46777, avg38840.01, stdev2813.37采样944次IOPS波动范围6.7k ~ 46.8k标准差2813写入Write性能write: IOPS16.6k, BW130MiB/s (136MB/s)(15.2GiB/120002msec)指标值说明IOPS16.6k每秒写入16,600次带宽130 MiB/s写入吞吐量总写入量15.2 GiB120秒内写入15.2GB写入延迟slat (nsec): avg5941.29 (~5.9 μs) clat (usec): avg2711.91 (~2.7 ms) lat (usec): avg2717.85 (~2.7 ms)写入平均延迟2.7ms比读取的2.1ms略高符合预期。写入延迟百分位数| 99.00th[ 4359], 99.50th[ 5342], 99.90th[103285], ...P99写入延迟 4.36ms读取是3.49msP99.9同样有100ms的尾延迟延迟分布直方图lat (usec): 1000.01%, 2500.01%, 5000.13%, 7501.04%, 10004.66% lat (msec): 241.95%, 451.32%, 100.59%, 200.01%, 500.11% lat (msec): 1000.02%, 2500.17%关键发现~93%的请求在4ms内完成1ms内4.66% 2ms内41.95% 4ms内51.32%~0.3%的请求超过50ms尾延迟总体分布中间密集2-4ms尾部有很长的拖尾CPU使用率cpu: usr3.95%, sys10.33%, ctx2211187, majf0, minf149指标值说明usr3.95%用户态CPU占比低fio本身计算量小sys10.33%内核态CPU占比处理I/Octx2,211,187总上下文切换次数约1.8万次/秒majf0无主缺页无磁盘swapminf149次缺页内存分配I/O深度统计IO depths: 10.0%, 20.0%, 40.0%, 80.0%, 160.0%, 32100.0%✅100%时间保持iodepth32说明磁盘能跟上队列深度没有出现队列积压不足的情况。submit: 00.0%, 4100.0%, ... complete: 00.0%, 4100.0%, ...批量提交/完成每次批量处理4个I/O符合libaio的批处理特性。I/O总量统计issued rwts: total4644062,1989240,0,0读操作4,644,062次写操作1,989,240次读写比例 70:30 ✓完全符合rwmixread70的配置磁盘级别统计Disk statssdd: ios5931652/2543396, sectors94906432/40694712, merge0/317, ticks11765239/6307868, in_queue18073398, util96.20%指标值说明util96.20%磁盘利用率96.2%接近饱和ios5.9M / 2.5M磁盘层面的读/写I/O数merge0 / 317读I/O完全没有合并写有少量合并in_queue18MI/O在队列中的总等待时间毫秒⚠️util96.2%是关键指标磁盘已经接近100%繁忙这是P99.9延迟飙升的根本原因
RELATED

相关推荐

FansAI × MINISO:从AI生成绿幕到170米天幕投放,一套无实拍户外广告的制作工作流

FansAI × MINISO:从AI生成绿幕到170米天幕投放,一套无实拍户外广告的制作工作流

世界杯期间的品牌营销,密度堪称一年里最高的时段之一。每个品牌都在争同一件事:怎么让消费者在信息洪流里停下来,记住你。 名创优品这次的答案是反套路——不买球星授权,把这笔预算直接还给消费者,创意本身足够清晰&a…

📅 2026/9/10 2:44:10
crypto-js AES ECB模式跨语言加解密避坑指南

crypto-js AES ECB模式跨语言加解密避坑指南

1. 项目概述:为什么ECB模式是“坑王”?如果你在项目里用过crypto-js做 AES 加密,尤其是 ECB 模式,大概率已经踩过几个不大不小的坑了。这个库用起来看似简单,CryptoJS.AES.encrypt一行代码搞定,但真到了要生…

📅 2026/9/6 1:12:18
连续折腾两周 AI 项目后,我发现真正影响开发效率的,从来不只是模型能力 —— 一次使用蓝耘 MaaS 的真实记录

连续折腾两周 AI 项目后,我发现真正影响开发效率的,从来不只是模型能力 —— 一次使用蓝耘 MaaS 的真实记录

最近这段时间,我一直在做一个自己想尝试很久的小项目。 项目目标并不复杂。 我想做一个自动化文本处理工具。 简单来说,就是把大量文章、PDF 内容或者长文本数据批量输入系统,然后自动完成摘要提取、关键词分析以及内容分类。 最开始我觉得这…

📅 2026/9/5 2:37:21
MORE NEWS

更多资讯

📰

FastAPI框架入门:高性能Python Web开发实战

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

📰

智能售货柜视觉流水线:IPC拉流、视频抽帧与YOLO部署实战

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

📰

SQL Server数据库文件恢复:MDF/NDF/LDF附加与日志重建实战

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

📰

告别EasyExcel:Apache POI才是Java Excel复杂场景的终极解

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

📰

MP4文件结构与Track轨道深度解析

/* MD / 富文本中的 .toc(含博客园搬家等嵌套结构);.toc-box 在侧栏,不受影响 */#content_views .toc,/* 编辑器常在目录前后插入空 p(:empty 仍占 20px),一并去掉避免顶空隙 */#content_views.markdown_views > p:empty:has(+ .toc),#content_views.markdown_views …

📰

AttBiLSTM实体关系抽取实践:结构、预处理与训练评估

简介:利用AttBiLSTM进行实体关系抽取,是自然语言处理与知识图谱构建中的关键任务。面向具备一定编程基础的初学者或研究人员,资源提供了一个轻量可运行的AttBiLSTM实体关系抽取实现,将双向LSTM的上下文建模能力与注意力机制的焦点…

TODAY

今日更新

THIS WEEK

本周精选

THIS MONTH

本月热门

读完文章,想聊聊您的网站?

告诉我们您的行业与需求,资深顾问一对一梳理方案与报价,全程免费。

📞 💬