1. FIO工具基础入门第一次听说FIO这个工具时我正被一个奇怪的磁盘性能问题困扰。当时我们的数据库响应时快时慢用常规方法根本找不出原因。直到一位老司机推荐了FIO我才发现原来磁盘性能测试可以这么专业。FIO全称Flexible I/O Tester是Linux平台下最强大的磁盘性能测试工具之一。它最大的特点就是能模拟各种真实的I/O负载场景不像dd命令只能做简单的顺序读写测试。你可以把它想象成一个I/O负载发生器能精确控制读写比例、块大小、队列深度等参数。安装FIO非常简单主流Linux发行版都可以通过包管理器直接安装# CentOS/RHEL sudo yum install fio libaio-devel -y # Ubuntu/Debian sudo apt-get update sudo apt-get install fio libaio-dev -y这里有个小坑要注意libaio-devel这个依赖包必须提前装好否则后面使用libaio引擎时会报错。我第一次用的时候就踩了这个坑折腾了半天才发现是依赖问题。FIO支持两种使用方式命令行直接执行和配置文件方式。新手建议从命令行开始等熟悉参数后再转用配置文件。比如测试随机读性能的基本命令长这样fio -filename/dev/sdb -direct1 -rwrandread -bs4k -ioenginelibaio -iodepth32 -runtime60 -numjobs4 -group_reporting -nametest这个命令会在/dev/sdb设备上用4个线程进行4K随机读测试队列深度32持续60秒。测试结果会自动汇总显示group_reporting的作用。2. 核心参数深度解析刚开始用FIO时最让我头疼的就是那一堆参数。后来经过多次实践才发现真正关键的参数就那几个理解后就能组合出各种测试场景。2.1 I/O模式控制三剑客rw参数决定测试的基本模式常用的有read/randread顺序读/随机读write/randwrite顺序写/随机写rw/randrw混合读写需配合rwmixreadbs参数设置I/O块大小这个对性能影响极大。4K、16K适合测随机IO1M适合测顺序吞吐。我一般会测试4K、64K、1M三个典型值。iodepth参数控制队列深度相当于同时发起的I/O请求数。SSD建议设置较大值32-128机械盘建议小些8-16。这个参数对IOPS影响很大我第一次测试时设成1结果SSD的性能连十分之一都没发挥出来。2.2 资源控制参数numjobs相当于并发 worker 数模拟多线程访问场景。但要注意不是越大越好超过CPU核心数反而会导致性能下降。我一般在4-16之间调整。runtime设置测试时长单位秒。太短可能结果不稳定太长又浪费时间。根据经验60秒是个不错的平衡点。size定义每个job的I/O总量。如果不设置runtime测试会持续到完成指定size的I/O为止。我常用5G这样中等大小的值。2.3 高级调优参数ioengine选择I/O引擎最常用的是libaioLinux原生异步I/O。如果是网络存储可能会用到rbd、http等引擎。direct1绕过系统缓存直接操作磁盘。这是性能测试的必备选项否则测的就是内存速度了。thread使用线程而非进程减少上下文切换开销。在多job测试时建议开启。这里有个真实案例我们曾测试一个NVMe SSD默认参数下IOPS只有5万。后来发现是ioengine用的sync同步模式换成libaio后直接飙到50万。所以参数选择真的能差出数量级3. 典型测试场景设计经过多次实战我总结出几个最常用的测试场景基本能覆盖大部分性能评估需求。3.1 纯读写性能测试随机读测试适合OLTP场景fio -filename/dev/nvme0n1 -direct1 -rwrandread -bs4k -ioenginelibaio -iodepth32 -runtime60 -numjobs4 -group_reporting -namerandread_test顺序写测试适合数据导入场景fio -filename/dev/nvme0n1 -direct1 -rwwrite -bs1M -ioenginelibaio -iodepth8 -runtime60 -numjobs4 -group_reporting -namewrite_test3.2 混合读写测试数据库这类应用通常是读写混合的可以用rwmixread参数控制比例# 70%随机读30%随机写 fio -filename/dev/nvme0n1 -direct1 -rwrandrw -rwmixread70 -bs8k -ioenginelibaio -iodepth16 -runtime120 -numjobs8 -group_reporting -namemixed_test3.3 真实场景模拟如果想更贴近业务可以设计复合场景。比如这个模拟MySQL的测试# 线程1随机读主键查询 # 线程2随机写DML操作 # 线程3顺序读全表扫描 # 线程4混合读写事务操作 cat mysql_sim.fio EOF [global] filename/dev/nvme0n1 direct1 ioenginelibaio iodepth16 runtime300 group_reporting [randread] rwrandread bs16k numjobs1 [randwrite] rwrandwrite bs8k numjobs1 [scan] rwread bs256k numjobs1 [txn] rwrandrw rwmixread70 bs4k-16k numjobs1 EOF fio mysql_sim.fio4. 测试结果深度解读FIO的输出报告信息量很大新手很容易看花眼。这里我拆解几个关键指标帮你快速抓住重点。4.1 性能三要素IOPS每秒I/O操作数随机读写场景的核心指标。我的经验值是SATA SSD5万-10万NVMe SSD50万-100万高端企业级SSD100万带宽(BW)吞吐量顺序读写时更重要。比如1M块大小顺序读理论带宽IOPS×1MB。延迟(lat)响应时间特别是99th百分位延迟。数据库场景要求99%的请求在10ms内完成。4.2 延迟分析FIO报告中有三种延迟slat提交延迟I/O下发到内核的时间clat完成延迟内核到I/O完成的时间lat总延迟slatclat重点关注clat的百分位数值。比如这个片段clat percentiles (usec): | 1.00th[ 128], 5.00th[ 142], 50.00th[ 164], | 95.00th[ 228], 99.00th[ 380], 99.50th[ 516], | 99.90th[ 1048], 99.95th[ 1256], 99.99th[ 1712]说明99%的请求在380微秒内完成性能很不错。如果99th值突然飙高可能是磁盘瓶颈。4.3 资源利用率cpu部分显示用户态(usr)和内核态(sys)的CPU占用。高IOPS测试通常sys占比很高。IO depths显示队列深度利用率。如果长期达不到设定值可能是设备瓶颈。util磁盘利用率。持续100%说明磁盘满负荷工作。5. 配置文件高级用法当测试场景复杂时命令行参数会变得很长。这时用配置文件会更方便也便于版本管理。5.1 基础配置文件把之前的混合测试改写成配置文件[global] filename/dev/nvme0n1 direct1 ioenginelibaio iodepth16 runtime60 group_reporting [randrw-70-30] rwrandrw rwmixread70 bs4k numjobs8 namemixed_test执行命令简化为fio config.fio5.2 多场景组合测试可以在一个文件里定义多个job[global] ...全局参数... [4k-randread] rwrandread bs4k numjobs4 name4k_random_read [1m-seqwrite] rwwrite bs1m numjobs2 name1m_sequential_write5.3 变量化配置支持变量让配置更灵活[global] ... filename${TEST_DEVICE} [job1] ... size${SIZE:-5G} # 默认值5G调用时指定变量TEST_DEVICE/dev/sdb SIZE10G fio config.fio6. 常见问题排查在长期使用FIO的过程中我积累了一些典型问题的解决方法。6.1 性能低于预期可能原因没设置direct1测的是缓存速度iodepth设置太小SSD需要足够队列深度numjobs超过CPU核心数导致频繁上下文切换排查步骤# 1. 确认direct I/O cat output | grep IOPS # 2. 检查CPU利用率 cat output | grep cpu : usr # 3. 逐步增加iodepth观察变化 for depth in 1 4 8 16 32 64; do fio -iodepth$depth ... | grep IOPS done6.2 测试结果波动大可能原因其他进程干扰用taskset绑定CPU核心磁盘本身性能不稳定企业级SSD也有GC影响解决方案# 绑定到特定CPU核心 taskset -c 0-3 fio ...6.3 设备被写满FIO测试会实际写入数据如果size设置太大可能填满磁盘。建议测试前用df检查空间设置runtime而非size控制时长使用lockmem限制内存用量7. 实战经验分享最后分享几个真实案例都是血泪教训换来的经验。7.1 数据库选型测试在为MySQL选存储时我们用FIO模拟了多种负载随机读模拟索引查询随机写模拟DML操作混合读写模拟真实业务发现某云盘的随机写延迟99th高达200ms直接排除了这个选项。最终选择的本地NVMe SSD即使在70%读30%写的混合负载下99th延迟也能控制在5ms内。7.2 参数调优案例一个MongoDB集群性能不佳用FIO测试后发现4K随机写IOPS只有5000增加iodepth后IOPS提升到20000但99th延迟从2ms升到50ms最终在IOPS和延迟之间找到了平衡点iodepth16时IOPS 1500099th延迟10ms。7.3 故障排查实例某次线上Redis变慢先用iostat发现磁盘util 100%但吞吐量很低。用FIO测试发现顺序读写正常随机读IOPS从正常的5000降到200延迟从1ms升到500ms最终确认是磁盘硬件故障更换后恢复正常。
1. FIO工具基础入门第一次听说FIO这个工具时我正被一个奇怪的磁盘性能问题困扰。当时我们的数据库响应时快时慢用常规方法根本找不出原因。直到一位老司机推荐了FIO我才发现原来磁盘性能测试可以这么专业。FIO全称Flexible I/O Tester是Linux平台下最强大的磁盘性能测试工具之一。它最大的特点就是能模拟各种真实的I/O负载场景不像dd命令只能做简单的顺序读写测试。你可以把它想象成一个I/O负载发生器能精确控制读写比例、块大小、队列深度等参数。安装FIO非常简单主流Linux发行版都可以通过包管理器直接安装# CentOS/RHEL sudo yum install fio libaio-devel -y # Ubuntu/Debian sudo apt-get update sudo apt-get install fio libaio-dev -y这里有个小坑要注意libaio-devel这个依赖包必须提前装好否则后面使用libaio引擎时会报错。我第一次用的时候就踩了这个坑折腾了半天才发现是依赖问题。FIO支持两种使用方式命令行直接执行和配置文件方式。新手建议从命令行开始等熟悉参数后再转用配置文件。比如测试随机读性能的基本命令长这样fio -filename/dev/sdb -direct1 -rwrandread -bs4k -ioenginelibaio -iodepth32 -runtime60 -numjobs4 -group_reporting -nametest这个命令会在/dev/sdb设备上用4个线程进行4K随机读测试队列深度32持续60秒。测试结果会自动汇总显示group_reporting的作用。2. 核心参数深度解析刚开始用FIO时最让我头疼的就是那一堆参数。后来经过多次实践才发现真正关键的参数就那几个理解后就能组合出各种测试场景。2.1 I/O模式控制三剑客rw参数决定测试的基本模式常用的有read/randread顺序读/随机读write/randwrite顺序写/随机写rw/randrw混合读写需配合rwmixreadbs参数设置I/O块大小这个对性能影响极大。4K、16K适合测随机IO1M适合测顺序吞吐。我一般会测试4K、64K、1M三个典型值。iodepth参数控制队列深度相当于同时发起的I/O请求数。SSD建议设置较大值32-128机械盘建议小些8-16。这个参数对IOPS影响很大我第一次测试时设成1结果SSD的性能连十分之一都没发挥出来。2.2 资源控制参数numjobs相当于并发 worker 数模拟多线程访问场景。但要注意不是越大越好超过CPU核心数反而会导致性能下降。我一般在4-16之间调整。runtime设置测试时长单位秒。太短可能结果不稳定太长又浪费时间。根据经验60秒是个不错的平衡点。size定义每个job的I/O总量。如果不设置runtime测试会持续到完成指定size的I/O为止。我常用5G这样中等大小的值。2.3 高级调优参数ioengine选择I/O引擎最常用的是libaioLinux原生异步I/O。如果是网络存储可能会用到rbd、http等引擎。direct1绕过系统缓存直接操作磁盘。这是性能测试的必备选项否则测的就是内存速度了。thread使用线程而非进程减少上下文切换开销。在多job测试时建议开启。这里有个真实案例我们曾测试一个NVMe SSD默认参数下IOPS只有5万。后来发现是ioengine用的sync同步模式换成libaio后直接飙到50万。所以参数选择真的能差出数量级3. 典型测试场景设计经过多次实战我总结出几个最常用的测试场景基本能覆盖大部分性能评估需求。3.1 纯读写性能测试随机读测试适合OLTP场景fio -filename/dev/nvme0n1 -direct1 -rwrandread -bs4k -ioenginelibaio -iodepth32 -runtime60 -numjobs4 -group_reporting -namerandread_test顺序写测试适合数据导入场景fio -filename/dev/nvme0n1 -direct1 -rwwrite -bs1M -ioenginelibaio -iodepth8 -runtime60 -numjobs4 -group_reporting -namewrite_test3.2 混合读写测试数据库这类应用通常是读写混合的可以用rwmixread参数控制比例# 70%随机读30%随机写 fio -filename/dev/nvme0n1 -direct1 -rwrandrw -rwmixread70 -bs8k -ioenginelibaio -iodepth16 -runtime120 -numjobs8 -group_reporting -namemixed_test3.3 真实场景模拟如果想更贴近业务可以设计复合场景。比如这个模拟MySQL的测试# 线程1随机读主键查询 # 线程2随机写DML操作 # 线程3顺序读全表扫描 # 线程4混合读写事务操作 cat mysql_sim.fio EOF [global] filename/dev/nvme0n1 direct1 ioenginelibaio iodepth16 runtime300 group_reporting [randread] rwrandread bs16k numjobs1 [randwrite] rwrandwrite bs8k numjobs1 [scan] rwread bs256k numjobs1 [txn] rwrandrw rwmixread70 bs4k-16k numjobs1 EOF fio mysql_sim.fio4. 测试结果深度解读FIO的输出报告信息量很大新手很容易看花眼。这里我拆解几个关键指标帮你快速抓住重点。4.1 性能三要素IOPS每秒I/O操作数随机读写场景的核心指标。我的经验值是SATA SSD5万-10万NVMe SSD50万-100万高端企业级SSD100万带宽(BW)吞吐量顺序读写时更重要。比如1M块大小顺序读理论带宽IOPS×1MB。延迟(lat)响应时间特别是99th百分位延迟。数据库场景要求99%的请求在10ms内完成。4.2 延迟分析FIO报告中有三种延迟slat提交延迟I/O下发到内核的时间clat完成延迟内核到I/O完成的时间lat总延迟slatclat重点关注clat的百分位数值。比如这个片段clat percentiles (usec): | 1.00th[ 128], 5.00th[ 142], 50.00th[ 164], | 95.00th[ 228], 99.00th[ 380], 99.50th[ 516], | 99.90th[ 1048], 99.95th[ 1256], 99.99th[ 1712]说明99%的请求在380微秒内完成性能很不错。如果99th值突然飙高可能是磁盘瓶颈。4.3 资源利用率cpu部分显示用户态(usr)和内核态(sys)的CPU占用。高IOPS测试通常sys占比很高。IO depths显示队列深度利用率。如果长期达不到设定值可能是设备瓶颈。util磁盘利用率。持续100%说明磁盘满负荷工作。5. 配置文件高级用法当测试场景复杂时命令行参数会变得很长。这时用配置文件会更方便也便于版本管理。5.1 基础配置文件把之前的混合测试改写成配置文件[global] filename/dev/nvme0n1 direct1 ioenginelibaio iodepth16 runtime60 group_reporting [randrw-70-30] rwrandrw rwmixread70 bs4k numjobs8 namemixed_test执行命令简化为fio config.fio5.2 多场景组合测试可以在一个文件里定义多个job[global] ...全局参数... [4k-randread] rwrandread bs4k numjobs4 name4k_random_read [1m-seqwrite] rwwrite bs1m numjobs2 name1m_sequential_write5.3 变量化配置支持变量让配置更灵活[global] ... filename${TEST_DEVICE} [job1] ... size${SIZE:-5G} # 默认值5G调用时指定变量TEST_DEVICE/dev/sdb SIZE10G fio config.fio6. 常见问题排查在长期使用FIO的过程中我积累了一些典型问题的解决方法。6.1 性能低于预期可能原因没设置direct1测的是缓存速度iodepth设置太小SSD需要足够队列深度numjobs超过CPU核心数导致频繁上下文切换排查步骤# 1. 确认direct I/O cat output | grep IOPS # 2. 检查CPU利用率 cat output | grep cpu : usr # 3. 逐步增加iodepth观察变化 for depth in 1 4 8 16 32 64; do fio -iodepth$depth ... | grep IOPS done6.2 测试结果波动大可能原因其他进程干扰用taskset绑定CPU核心磁盘本身性能不稳定企业级SSD也有GC影响解决方案# 绑定到特定CPU核心 taskset -c 0-3 fio ...6.3 设备被写满FIO测试会实际写入数据如果size设置太大可能填满磁盘。建议测试前用df检查空间设置runtime而非size控制时长使用lockmem限制内存用量7. 实战经验分享最后分享几个真实案例都是血泪教训换来的经验。7.1 数据库选型测试在为MySQL选存储时我们用FIO模拟了多种负载随机读模拟索引查询随机写模拟DML操作混合读写模拟真实业务发现某云盘的随机写延迟99th高达200ms直接排除了这个选项。最终选择的本地NVMe SSD即使在70%读30%写的混合负载下99th延迟也能控制在5ms内。7.2 参数调优案例一个MongoDB集群性能不佳用FIO测试后发现4K随机写IOPS只有5000增加iodepth后IOPS提升到20000但99th延迟从2ms升到50ms最终在IOPS和延迟之间找到了平衡点iodepth16时IOPS 1500099th延迟10ms。7.3 故障排查实例某次线上Redis变慢先用iostat发现磁盘util 100%但吞吐量很低。用FIO测试发现顺序读写正常随机读IOPS从正常的5000降到200延迟从1ms升到500ms最终确认是磁盘硬件故障更换后恢复正常。
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
