我平时排查线上服务器性能问题十次有八次最后都会落到磁盘I/O上。CPU飙高可以用top快速定位进程内存不够看free就能确认唯独磁盘这块很多人习惯性用top看一眼就略过结果漏掉了真正的瓶颈。如果想让服务器“开口说话”iostat是你必须先掌握的工具之一。iostat是Linux系统自带的I/O性能监控命令全称是I/O statistics由sysstat包提供。它能实时报告磁盘的读写速率、I/O请求等待时间、队列长度、利用率等关键指标是定位磁盘瓶颈、评估存储性能、验证调优效果时最常用的命令行工具。无论你是刚接触Linux的运维新手还是已经写了几年脚本的开发只要你的程序需要读写磁盘iostat就能帮你回答一个核心问题磁盘到底忙不忙忙在哪里。这篇文章不会照搬man手册我结合自己实际排查过的案例把iostat的关键参数、输出字段、常见误区和排查套路一次讲清楚。1. iostat到底能做什么1.1 它和top、vmstat这些命令有什么不同很多人觉得监控性能用top就够了确实top能看到CPU、内存、负载的大致情况但它对磁盘的展示非常有限。top默认只显示进程级别的I/O等待时间wa指标并不会告诉你底层磁盘的读写速度、请求队列有多长、每个I/O请求平均要等多久。这些信息恰恰是判断磁盘是否成为瓶颈的关键。iostat专注的就是这一层。它直接读取内核维护的块设备统计信息/proc/diskstats输出的是整个磁盘控制器、单块磁盘或分区的I/O活动情况而不是某个进程的行为。换句话说top回答的是“哪个进程在消耗资源”iostat回答的是“底层磁盘设备本身状态如何”两者正好互补。实战中你经常需要这样配合先用top发现wa偏高或某个进程I/O等待严重再用iostat确认是不是磁盘设备本身扛不住了最后用iotop或pidstat定位到具体进程。1.2 典型使用场景我总结下来iostat最常用的场景是这几类磁盘性能瓶颈判断。数据库响应突然变慢、文件服务器吞吐下降、应用大量报超时第一个要怀疑的就是磁盘。iostat的%util和await能快速告诉你磁盘是不是已经饱和了。存储选型和压测验证。买新服务器或云盘时云厂商给的IOPS、吞吐量参数都是理论值实际表现可以自己压测用iostat验证。我之前评估过一块SSD的真实写性能就是靠iostat的wkB/s指标确认的。系统调优前后的对比。调整了I/O调度算法、文件系统挂载参数、数据库刷盘策略之后有没有效果不能靠感觉得用数据说话。iostat前后各采一次指标对比一目了然。排查突发的I/O抖动。明明没有大业务量磁盘利用率却飙到90%以上用iostat配合定时任务抓历史数据往往能抓到罪魁祸首是日志清理脚本、备份任务或者某个定时扫描。1.3 哪些人必须熟练掌握如果你是运维工程师iostat应该是肌肉记忆级别的命令。数据库管理员更要精通MySQL或PostgreSQL的慢查询很多根因都在磁盘。后端开发做性能分析时也离不开它——你的服务性能压测报告里如果缺少磁盘I/O数据说服力会大打折扣。即便你是个人开发者自己搭的NAS或家用服务器变卡了iostat也能帮你快速了解原因。2. 常用参数和输出字段的详细解读2.1 最常用的几个参数组合iostat的语法本身很简单iostat [选项] [时间间隔] [次数]不带任何参数直接运行显示的是系统启动以来的平均统计参考意义不大实战中我们几乎总是配合参数和间隔使用。下面这几个组合是我日常使用频率最高的# 每2秒刷新一次共显示5次显示扩展统计信息 iostat -x 2 5 # 显示所有设备的统计信息包括未挂载的以MB为单位 iostat -d -m 2 # 查看某个特定磁盘的详细情况 iostat -x /dev/sda 2 3 # 显示CPU统计信息不显示磁盘信息 iostat -c 1 2 # 显示某个分区的统计信息 iostat -p /dev/sda1 2 3参数含义拆解一下-x显示扩展统计信息。这是最关键的参数不看这个你等于没学iostat。它额外提供await、%util、svctm等指标用于判断磁盘健康状况。-d仅显示磁盘设备状态不显示CPU信息。适合只想看磁盘的时候输出更干净。-k/-m分别以KB/s和MB/s为单位显示读写速率。默认单位是块block是512字节直接用块数看数据很难受我几乎总是加-m或-k。-t在输出中打印时间戳。做长时间采集时建议加上方便后续按时间点回溯。-c仅显示CPU统计信息。这个配合脚本抓取CPU的iowait值很方便。-p显示指定磁盘分区如/dev/sda1的统计信息。-h人类可读格式配合-x使用效果更好不过部分旧版本不支持。2.2 输出字段逐项解析运行iostat -x -m 1 1后你会看到类似这样的输出Linux 5.15.0-91-generic (web-server-01) 2024-06-15 _x86_64_ (8 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 12.35 0.00 3.21 8.67 0.00 75.77 Device r/s w/s rMB/s wMB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz %util sda 23.45 67.89 1.23 8.45 0.00 4.56 0.00 6.29 1.20 15.60 1.23 53.50 127.30 42.10CPU统计部分avg-cpu行%iowaitCPU等待I/O完成的时间百分比。这个值偏高比如持续超过20%说明有进程在等磁盘I/O。注意它高不代表磁盘一定有问题只是说明CPU在等待最终还要结合磁盘字段来判断。%idleCPU空闲百分比。有一种典型情况是%iowait很高但%idle也不低这时候往往是I/O请求已经排队磁盘忙不过来了。磁盘统计部分核心字段r/s和w/s每秒完成的读请求次数和写请求次数。单位是次数不是数据量。这两个值合起来就是设备每秒能处理的I/O请求总数上限取决于磁盘本身的IOPS能力。比如一块普通的SATA机械盘随机读写的IOPS大概在100-200之间如果r/s加w/s长期在200以上且持续上涨说明磁盘快饱和了。而SSD的IOPS可以轻松上万同样数值对SSD来说还很轻松。rMB/s和wMB/s每秒读写的吞吐量。这个是数据量指标反映的是带宽占用情况。机械盘的顺序读写带宽大概在150-200MB/sSSD根据接口不同能从几百MB/s到好几GB/s。这两个值主要和业务读写的数据量有关。rrqm/s和wrqm/s每秒合并的读请求和写请求数。Linux的I/O调度器会把相邻的、可以合并的请求合并成一个更大的请求再下发到磁盘这样能有效提升效率。合并数高说明磁盘收到的是顺序且密集的I/O这是好现象。如果合并数低但单位请求的数据量大说明是少量大块的随机I/O。r_await和w_await读请求和写请求的平均响应时间单位是毫秒。这是判断磁盘延迟的核心指标直接反映了每一次I/O请求从发起到完成需要多长时间。经验值SSD的await通常在1-3ms高性能云盘在5ms左右机械盘在10-20ms左右。如果await超过30ms甚至100ms以上磁盘基本可以确定是瓶颈了。aqu-sz平均I/O队列长度。这个值表示请求在队列中排队的数量。数值越大说明排队越严重磁盘处理不过来了。这个字段在部分系统上可能只显示为0这是正常的因为它是采样周期内的平均值瞬时尖峰不一定能体现在这个数字里。rareq-sz和wareq-sz平均每次读/写请求的数据大小单位KB。顺序读写的请求大小通常比较大几十KB甚至几百KB随机读写的请求则很小4KB、8KB之类。通过这个字段可以基本判断业务的I/O模式。如果wareq-sz长期只有几KB但w/s又很高那基本可以认定为大量小文件随机写场景。%util设备利用率这个字段最直观也最容易被误读。它表示采样周期内设备处理I/O请求的时间百分比。这里的误读点在于%util趋近100%只说明设备在整个采样周期内始终有I/O请求在服务中并不代表磁盘性能已经到极限了。多块磁盘组成的阵列、NVMe SSD这类高并发设备即使能处理的请求数还很多%util也可能显示100%。2.3 关于svctm这个字段要注意老版本iostat里有svctm字段I/O服务时间这个指标曾经被广泛引用但它其实是通过计算得出的估算值在部分场景下并不准确新版本iostat已经默认不显示这一字段了。如果你在网上看到老文章让你重点看svctm建议以await和%util为主来判断不要过度依赖svctm。3. 一次真实的MySQL磁盘瓶颈排查过程3.1 接到告警慢查询暴增QPS骤降这里分享一次我用iostat定位问题的实际经历。当时线上一个MySQL实例突然出现大量慢查询应用侧反馈接口耗时从平均50ms飙到800ms以上。我第一反应是看慢查询日志发现大量update语句执行时间超过3秒。此时直接冲进数据库去看执行计划意义不大因为表结构和索引一直没变问题几乎可以肯定出在底层I/O上。3.2 三步确认磁盘是罪魁祸首第一步先看系统整体负载和CPU状态toptop输出显示waI/O wait已经到30%以上CPU user也偏高但这个信息只能说明CPU大量时间在等I/O还不能锁定磁盘具体状态。第二步上iostat看磁盘iostat -x -m 1 5连续采集5秒后关键指标是这样的Device r/s w/s rMB/s wMB/s rrqm/s wrqm/s r_await w_await aqu-sz %util vdb 15.30 245.00 0.50 14.50 0.00 18.50 12.50 55.30 9.50 100.20当时就看出问题了w/s高达245w_await到了55ms左右aqu-sz接近10%util稳定在100%。这四个指标共同说明磁盘已经严重饱和写请求在排队每个写的响应时间被拉得很长。这块云盘应该是SSD正常情况下w_await应该在5ms以内现在55ms明显不正常。第三步查看具体是什么在写iostat只告诉你磁盘满了不告诉你谁在写。这时候我用pidstat进一步定位pidstat -d 1 5确认是mysqld进程在大量写入。再去看MySQL的刷盘机制和binlog策略发现binlog刷盘策略被改成了每次事务提交都刷盘sync_binlog1加上redo log的刷盘策略也是每次提交都刷innodb_flush_log_at_trx_commit1在写入量大的业务场景下磁盘I/O压力会被成倍放大。3.3 处理方案和数据对比确认了根因是磁盘能力不足且配置对磁盘要求过高后当时的处理分了两步先协调云平台把数据盘升级到更高IOPS规格的云盘从底层解决能力问题。同时把binlog刷盘策略从sync_binlog1调整为sync_binlog0让操作系统决定何时刷盘这一步显著降低了每次事务提交带来的磁盘同步写压力。升级和调整后再跑一次iostat验证iostat -x -m 1 5w_await从55ms降到6ms%util从100%降到40%左右QPS恢复到正常水平接口耗时回到50ms以内。整个排查过程不到20分钟iostat提供的关键指标直接帮我把问题范围缩小到了磁盘层没有在SQL优化、慢查询分析上浪费时间。3.4 这个案例给我们的启示现在回顾这个案例有几个细节值得强调只看%util为100%是不够的要同时看w_await。如果w_await很低比如1-2ms那100%利用率可能只是高并发下的正常状态未必是瓶颈。只有当%util和await同时高企才能确认磁盘真的处理不过来。遇到数据库变慢先看磁盘再看SQL是有道理的。I/O瓶颈会放大所有SQL的延迟哪怕一条平时只要2ms的查询在磁盘饱和时也可能变成200ms。升级配置和调整参数后一定要用iostat重新采样对比让数据告诉你调整有没有效果不要凭感觉觉得“好像好了”。4. 进阶玩法让iostat输出会“说话”4.1 理解%util的局限性前面提到%util在NVMe等高性能设备上容易“虚高”这里稍微展开讲一下。%util的计算方式是采样周期内设备忙的时间除以总时间它本质上是一个“是否忙”的二进制信号而不是“有多忙”的线性度量。打个比方一个外卖员一整天都在送单路上路上没停过我们说他的“利用率”是100%。但对他来说可能每个订单都很顺利利用率100%不代表他崩溃了。磁盘也是同样的道理——只要队列里始终有请求在跑%util就是100%可如果磁盘硬件很强每个请求响应只要1ms那这个100%并不代表性能瓶颈。所以我的建议是不要把%util单独当作“磁盘是否已经到极限”的唯一标准务必和await、aqu-sz、r/s、w/s放在一起看%util高 await正常 w/s未达到硬件上限 → 高并发但健康%util高 await高 aqu-sz持续增长 → 磁盘饱和需要扩容或优化%util不高 await高 → 可能是单个大请求阻塞比如机械盘的寻道或者磁盘有硬件问题4.2 连续采集和趋势分析单次iostat输出只是某一瞬间的快照排查性能问题时更可靠的做法是连续采集一段时间形成数据趋势。我之前排查一个间歇性卡顿的问题时写过这样一个简单的后台采集命令iostat -x -m 1 60 /tmp/iostat_$(date %Y%m%d_%H%M%S).log 21 这条命令会采集60次数据每秒一次输出到带时间戳的日志文件里。等故障复现后去翻日志就能看到故障前后磁盘指标的变化轨迹。如果需要历史数据做对比也可以把iostat结果输出到文件长期保留写个简单的脚本做趋势分析。另外配套sadf命令可以输出更友好的格式sadf -d -- -x 1 5sadf是sysstat包自带的工具能把iostat的输出转换成CSV格式方便导入Excel或数据库做后续分析。这在需要出报告给团队或客户看时非常有用。4.3 结合其他命令交叉验证iostat虽然强大但不该独立承担所有诊断责任。我在实际工作中会这样组合使用vmstat看整体I/O等待vmstat 1 5看r运行队列和wa列。如果r持续大于CPU核数同时wa很高说明系统确实在I/O等待上卡住了。iotop看进程级I/Oiotop -o -Piostat能看到磁盘的状态但它不告诉你到底是哪个进程在写。要定位进程用iotop需要root权限或对应capability它能动态显示每个进程的读写速度。pidstat轻量版进程I/O统计pidstat -d 1 5如果系统没装iotoppidstat的-d参数也能输出每个进程的读写速度和I/O操作数配合iostat使用一般就能完整回答“磁盘忙不忙、谁在让它忙”这两个问题。用dd或fio手动压测验证如果想验证磁盘的真实性能上限可以先用dd做一个简单的顺序读写测试dd if/dev/zero of/tmp/testfile bs1M count1024 convfdatasync跑完再用iostat采样确认实际吞吐。更严谨的测试工具推荐fio可以模拟各种随机读、随机写、顺序读、顺序写场景配合iostat验证结果是存储性能评估的标准姿势。4.4 用iostat验证RAID和云盘性能这里再补充一个实用场景。很多公司的服务器用的是RAID阵列或云盘这类存储的逻辑设备性能并不是简单叠加物理盘就能算出来的。我在给一个项目做存储选型对比时连续一周用iostat定时采集两块不同规格云盘的指标最后通过r_await和w_await的对比发现其中一块云盘在高并发随机写场景下延迟波动极大果断放弃了那个方案。iostat在选型阶段的价值很多人容易忽略但它确实是一个低成本、可信度高的判断依据。5. 常见误区与实际坑点5.1 误区一把%util当成磁盘性能上限这是最常见的误读前面已经展开说过。再补充一个例子NVMe SSD在队列深度较高时%util可以轻松达到100%但此时磁盘完全没有成为瓶颈因为硬件本身的处理能力远超负载的需求。判断磁盘是否成为瓶颈不能只看%util要综合await、aqu-sz、r/s、w/s和设备硬件参数。5.2 误区二用不带-x参数的iostat判断性能问题默认iostat只显示基础的r/s、w/s、rkB/s这些没有await和%util等于丢掉了一半有用的信息。我见过有人用默认输出看了一下觉得“读写速率不高啊磁盘没问题”实际上此时await已经高到离谱。记住判断性能问题-x是标配。5.3 误区三第1次采样数据就下结论iostat第1次输出的数据统计的是系统启动以来的平均值。如果没有指定间隔它会直接显示这个平均数据如果指定了间隔第1次显示的仍然是启动以来的均值从第2次开始才是间隔内的真实数据。所以我建议在采样时多等几次看后几次的数据iostat -x -m 2 3第1行是自启动以来的平均值第2行和第3行才是关键数据。如果脚本里要抓取iostat数据做监控务必跳过第一次输出。5.4 误区四漏采样问题iostat在输出时间间隔较短时有可能出现某次采样没有数据的情况显示为全0这是正常的不需要过分担心。特别是当你用iostat 1这种1秒间隔采样时如果当时磁盘确实没有I/O活动输出全0是合理的。但如果一个长时间运行的采样中频繁出现全0而业务又明明在大量读写就要检查是不是有LVM、磁盘阵列等中间层把统计信息合并或转移了。5.5 误区五只盯平均值忽略波动iostat输出的是采样间隔内的平均值平均值为正常不代表没有瞬间尖峰。比如一个持续1秒的毛刺如果采样间隔是5秒它会被摊薄成20%的变化看起来不痛不痒。如果你怀疑有偶发的I/O尖峰就把采样间隔缩短用iostat -x -m 1持续观察一段时间或者把采集频率加密。5.6 关于iostat命令缺失的处理有些精简版系统默认没有安装iostat执行时会提示command not found。它属于sysstat包安装方式很简单Debian/Ubuntu系统apt update apt install sysstat -yCentOS/RHEL系统yum install sysstat -y安装后确认版本iostat -V需要注意sysstat包还包含了sar、mpstat、pidstat等常用的性能监控命令建议一起掌握都是同一个系列的利器。6. 实操建议一次标准的I/O排查流程严格来说iostat本身不带什么复杂的配置但把它嵌入到一套完整的排查流程中价值才会最大化。这里把我平时处理磁盘相关问题时的一套标准流程整理出来先确认现象。是什么表现让你觉得磁盘有问题变慢、报错、卡顿还是监控告警把现象描述清楚带着问题去查不要一上来就乱敲命令。看整体负载。用top或uptime确认load average情况用vmstat 1 5看wa列。如果wa很高重点考虑I/O。用iostat锁定设备。执行iostat -x -m 1 5重点看r_await、w_await、aqu-sz、%util这几个值。如果await偏高、%util接近100%设备层问题基本就确认了。定位进程。用pidstat -d 1 5或iotop -o -P找到具体是哪个进程在产生大量I/O。这一步是关键iostat能告诉你是磁盘病了但“治谁”需要进程级数据。对症处理。如果是磁盘饱和要么升级设备、要么优化业务层的I/O模式减少随机写、合并写、加缓存等如果是进程异常那就去排查应用的逻辑问题。验证结果。处理完再用iostat重新采样对比确认指标回到合理范围。这套流程我用了很多年也推荐给了不少同事核心思路就是“由面到点、层层缩小范围”避免在排查时东敲一个命令西敲一个命令漫无目的。最后说一个我个人的习惯我会在服务器上放一个简单的脚本定时把iostat和pidstat的输出写到日志目录保留最近30天。这样出了问题可以直接翻故障发生时间点的历史数据不用等到故障复现再去现场抓数据。这个习惯已经帮我省了好几次半夜爬起来排查的力气。