Linux性能排查利器iostat命令详解：CPU与磁盘I/O监控实战

做Linux性能排查iostat命令是我每次必用的性能监控工具之一。它不像vmstat那样只给个整体概况也不像sar那样要事后翻历史曲线iostat能在现场直接输出CPU和磁盘的实时I/O统计几秒钟就能判断系统到底卡在CPU还是卡在磁盘。无论是看数据库服务器变慢、定位日志写盘异常、还是排查虚拟机宿主机的高负载问题iostat都是第一梯队要上的命令。这篇就围绕iostat命令本身把安装、参数、输出指标、常见坑和实战判断思路一次讲透适合刚接触Linux运维的初学者也适合那些已经会敲iostat但不知道输出结果意味着什么的人。1. iostat是什么先从整体认识这个性能监控工具1.1 它来自sysstat工具包和sar同门iostat全称是I/O statistics意思是输入输出统计它并不是一个孤零零的命令而是sysstat工具包里的成员。sysstat包里还有sar、mpstat、pidstat、cifsiostat这些常用工具它们都共用一套内核数据读取机制所以如果你装过sariostat大概率已经躺在系统里了。排除掉少数定制化系统的特殊情况iostat的数据来源是内核维护的/proc/stat和/proc/diskstats这两个虚拟文件。proc目录不是真正存在磁盘上的文件它是由内核动态生成的窗口iostat做的事就是定时去读这些计数器的数值然后计算两次采样之间的差值再除以间隔时间换算成每秒的速率。这也是为什么iostat必须“隔一段时间采样两次以上”才能算出速率单独跑一次不带参数的命令它显示的是开机到现在的平均数据。这个数据来源决定了iostat能看到非常底层的真实情况它绕过文件系统缓存直接反映块设备层的I/O行为这是很多应用层工具做不到的。比如你通过df看到磁盘满了通过top看到CPU跑满了但磁盘到底有多少读写压力、请求平均等多久、设备忙不忙这些只有通过iostat这类块设备层工具才能看到。1.2 核心功能一块看CPU一块看磁盘iostat的输出天然分成两大块这是它设计上最直观的特点。第一块是CPU使用率统计占据顶部区域包含%user、%system、%iowait、%idle等字段可以快速判断CPU是不是被用户程序占满或者系统CPU花在等待I/O上。第二块是设备使用率统计也就是Device表。默认情况下它列出的是系统里的物理磁盘和分区比如sda、sdb、nvme0n1这些每一行都是一个独立的块设备。这块表里的列很多包含每秒传输次数tps、每秒读写的数据量、平均I/O等待时间await、设备繁忙程度%util等这也是iostat作为“性能监控工具”最核心的价值所在。这两块数据的意义在于配合判断。CPU的%iowait指标抬高只能告诉你“有程序在等I/O完成”但具体是哪个磁盘拖后腿、等多久、请求积压多少必须看下面设备表里的指标。很多新手只盯CPU看到%iowait高就慌却不知道源头在哪iostat把这两块放在同一个输出里就是为了让人能快速联动分析。1.3 这东西适合谁来用能解决什么问题iostat适合的角色非常广。如果你是Linux运维工程师服务器无端变慢、数据库查询变慢、应用超时报警这些场景基本绕不开iostat。如果你是开发人员程序执行效率低、批量任务跑得慢也可以用它确认瓶颈是不是落在磁盘I/O上而不是一上来就怀疑代码有问题。如果你是面试官视角Linux命令里iostat出现的频率很高能准确讲清楚%util、await、svctm含义的候选人至少在性能排查方面是有点底子的。它能解决的典型问题包括确认系统瓶颈是CPU还是磁盘、定位是读瓶颈还是写瓶颈、判断某块磁盘是否已经饱和、验证调整参数后I/O性能有没有改善。它解决不了的问题也要心里有数iostat看不到具体是哪个进程在读写这要配合pidstat、iotop这类工具它也看不到文件系统缓存层面命中多少这要结合free和/proc/meminfo判断。先知道工具边界用起来才不会走弯路。2. 安装与基础用法两条命令让你快速上手2.1 不同发行版的安装方式iostat通常不是最小化安装自带的命令如果你敲iostat提示command not found直接装sysstat包就行。不同发行版的包管理器不一样安装命令差别不大我列一下最常见的几类# Debian / Ubuntu 系列 apt install -y sysstat # CentOS / RHEL / Rocky / AlmaLinux 系列 yum install -y sysstat # 较新版本的 RHEL 系列用 dnf dnf install -y sysstat # openSUSE / SUSE zypper install -y sysstat # Arch / Manjaro pacman -S sysstat装完之后可以先跑一个iostat -V确认版本不同版本的输出字段会有细微差别比如较新的内核和sysstat版本里%util的定义发生过调整后面会专门讲。这里先提醒一句如果apt或yum源里找不到多半是软件源问题不是命令本身的问题更新软件源再装。另外sysstat包通常会附带安装一个定时任务通过cron或systemd timer来定时收集性能数据到/var/log/sysstat目录这是给sar用的历史数据源。iostat本身是随用随跑的实时工具你不依赖历史库也一样能用不冲突。2.2 命令格式与常用参数清单iostat的命令格式非常规整基本可以概括为iostat [选项] [间隔时间] [次数]重点是间隔时间和次数这两个位置参数。间隔时间以秒为单位次数表示采样输出多少次。比如iostat 2表示每2秒输出一次一直循环iostat 2 5表示每2秒输出一次总共输出5次后就退出。实际排查问题的时候我几乎总是用iostat -x 1 5这个组合-x表示扩展统计1秒间隔采样5次既能覆盖一段时间的变化趋势又不会让终端刷屏刷到失控。常用参数我整理成一个表格对照着看会更清楚参数作用使用要点-c仅显示CPU使用率配合-d可单独确认CPU侧状态-d仅显示磁盘I/O统计输出更聚焦推荐日常使用-k以KB为单位显示数据量默认单位是块不直观-m以MB为单位显示数据量大吞吐场景比-k更易读-x扩展统计显示更多指标排查瓶颈时必加-t在输出中显示时间戳记录现场数据时很实用-z不显示活动为0的设备服务器磁盘很多时避免刷屏-h让输出更可读面向NFS等信息常规磁盘用不太上-y跳过第一次无间隔的统计信息配合循环采样时更准确参数之间可以组合比如iostat -dxk 1 5表示以KB为单位、只看磁盘、扩展统计每秒一次共5次这是我很常用的组合。注意不要在一个命令里同时加-k和-m单位会打架系统会取最后一个生效反而容易误导。2.3 最常用的几种调用方式第一种就是机房里最经典的裸奔式调用直接敲iostat。这个不带任何参数输出的是开机累计平均值虽然不够实时但可以快速看一个整体概况比如系统是不是从启动到现在磁盘负载一直很高。第二种是我说的iostat -dxk 1 5这是标准实时体检。1秒的间隔比较激进能捕捉到瞬时尖峰如果你想看平稳趋势把间隔拉到5秒或10秒更合适比如iostat -dxk 5 5这样采样的是5秒均值噪音会小很多。第三种是单独盯CPUiostat -c 1 3这在怀疑CPU比磁盘更紧张的时候用。注意-iowait这个指标它反映的是CPU花在等待I/O完成上的时间比例这个值如果持续偏高用iostat自己的话来说就是“CPU在等磁盘干活”这时候你再切到-dx看设备详情整个过程很顺。提示无论用哪种调用方式采样次数都别设太少。至少3次以上再开始分析因为第一次输出往往是当前瞬时状态的快照波动很大。iostat -y参数可以跳过第一次无间隔的统计做基准对比时很有用。3. 输出结果逐项拆解CPU和磁盘指标到底怎么看3.1 第一块CPU使用率的几个字段用iostat -c 1 3跑出来的输出头部会显示系统版本、日期和CPU核数然后是一段avg-cpu表。这张表在非-x模式下显示的是百分比各字段加起来接近100。常见字段有%user、%nice、%system、%iowait、%steal和%idle。%user表示用户态程序占用的CPU百分比%nice是低优先级用户态程序的占比%system是内核态占比%iowait表示CPU等待I/O完成的时间占比%steal是虚拟机环境下被宿主机抢走的时间占比%idle就是完全空闲的比例。这几个里面%iowait是最值得留意的它一高就说明有任务在等I/O但要注意%iowait高不高得多配合设备表看如果%iowait很高但设备表的%util并不高可能问题出在锁竞争、内存换页或者文件系统层。读这段数据有个姿势上的讲究别孤立看某一次采样要看连续几次的变化趋势。比如%iowait从5%一路涨到40%同时%user不变那基本可以断定磁盘侧出问题了如果%user本身就95%以上那就是典型的CPU饱和这时候再纠结磁盘没有意义。3.2 第二块Device表里的关键指标Device表是iostat的精华尤其加了-x参数后列数会突然变多很多人就是在这里开始看不懂的。默认模式下有tps、kB_read/s、kB_wrtn/s、kB_read、kB_wrtn这几列-x模式下则多了r/s、w/s、rrqm/s、wrqm/s、r_await、w_await、aqu-sz、rareq-sz、wareq-sz、svctm、%util一堆字段。逐一说太啰嗦我挑几个最关键的讲。r/s和w/s是每秒读请求数和写请求数这个“请求”不是应用层的read/write调用而是真正下发到块设备层的I/O请求所以它会比你在应用层看到的磁盘操作次数更贴近硬件。rkB/s和wkB/s是每秒读写的数据量单位取决于你用-k还是-m。rrqm/s和wrqm/s是每秒合并的读、写请求数I/O调度器会把相邻的小请求合并成大请求这个值越高说明合并效率越好对机械盘特别有利。r_await和w_await是读、写请求的平均等待时间单位毫秒这个指标非常直观地反映“发出请求到完成”的延迟是判断磁盘健康度的核心。aqu-sz是平均队列长度代表有多少请求在排队。svctm是平均服务时间也就是磁盘实际处理一个请求花的时间。最后是%util设备繁忙百分比算法是服务时间除以采样周期。这几个指标之间不是孤立的它们的关系才是判断瓶颈的关键。3.3 关键指标之间的关系与判断思路很多人对iostat有个误解以为%util到100%就意味着磁盘“满了”这其实不太准确。%util反映的是设备繁忙的时间占比但磁盘和CPU一样处理请求是可以并行的尤其现在SSD普遍是多队列设备%util跑到100%不代表性能就到顶了。举个更生活化的例子一条只允许一辆车通过的单车道一旦有车在上面这条路就100%占用但它的吞吐量很有限而一条八车道高速路随时都有车在跑占用率也高但单位时间通过的车辆数远大于单车道。所以判断磁盘是否成为瓶颈我建议按这个顺序看先看%util是不是长期接近100%再看await是不是明显高于svctm然后再看aqu-sz是不是持续增长。如果%util高、await远超svctm、队列长度也在涨这三个同时满足说明设备确实忙不过来请求在排队这就是真正的瓶颈。反过来%util高但await和svctm差不多队列长度也没有堆积那可能只是设备在处理大量请求但还应付得来。这里有个经典的坑要提醒老版本sysstat里svctm这个指标是统计出来的新版本里它已经通过公式计算在有的内核版本上计算方式发生过调整所以svctm数值本身参考意义大于精确意义不要用svctm去硬套“服务时间必须小于await”这种结论。更重要的是理解await和队列的增长逻辑。注意读await、aqu-sz、%util这三个指标时一定要结合采样周期和I/O类型看。顺序读大文件时即使磁盘很忙await也未必高但随机小IO密集时即使%util看起来不高await也可能已经很高。换句话讲没有万能指标组合着读才能下结论。4. 实战记录用iostat -x 1 5定位一次数据库卡顿4.1 问题背景与初步判断有一回帮朋友看一个MySQL数据库服务器现象是业务侧反馈写入变慢前端接口偶尔超时。服务器本身配置不低CPU是16核内存64G系统盘和数据盘分开数据用的是两块SSD做的软RAID1。朋友的初步怀疑是数据库连接数不够加了连接数上限之后问题还在于是让我上服务器看。我先跑了一遍uptime和top发现load average差不多在8左右对16核机器来说不算爆表但%wa这一项大概有20%多。这个%wa就是top里显示的I/O等待占比比平时明显高。这个时候我基本锁定了方向问题大概率出在I/O侧而不是CPU算力不够。为了拿到更确切的证据我把iostat叫上阵。4.2 现场抓取数据并逐行解读我当时执行的命令是iostat -dxk 1 5输出非常清晰。第一段显示的是系统信息和CPU汇总%iowait大概稳定在18%到23%之间。第二段设备表里最显眼的是sda这块盘也就是数据盘所在的设备几乎每一行都是满负荷状态。截取其中一次采样的关键字段大概是这样的Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util sda 12.00 156.00 120.00 50400.00 0.00 210.00 0.00 57.00 8.00 180.00 18.50 10.00 323.00 6.00 100.00我来拆解一下这张表的判断逻辑。w/s有156这个数量不算高但wkB/s有50400约50MB/s的写入量说明每次写请求的数据量不小wareq-sz显示平均写请求大小约323KB典型的日志顺序写特征。真正扎眼的是w_await写等待平均180毫秒而svctm只有6毫秒差距非常悬殊说明写入请求大部分时间不在设备上真正执行而是在队列里干等。aqu-sz队列长度18.5持续积压%util长时间卡在100%。这三个现象组合在一起结论已经很明显了这台机器的数据盘在处理写入时已经是排队状态磁盘的写吞吐跟不上业务产生的写入量。SSD本身的svctm很低但它扛不住请求堆积带来的等待激烈上升表现在业务上就是写请求超时、接口响应变慢。4.3 定位结论与后续处理建议确认磁盘写瓶颈之后我趁热打铁又用pidstat -d 1 5看是哪个进程在大量写盘结果抓到了mysqld这跟业务反馈的数据库写入慢吻合。然后登录MySQL用SHOW ENGINE INNODB STATUS和慢查询日志确认发现有一个批量更新任务在频繁提交小事务同时binlog和redo log都落在同一块数据盘上刷盘压力集中爆发。处理方案分了几步。第一步是临时缓解把批量更新任务拆小减少同时提交的事务数拉平写入峰值这个操作当天就让w_await从180毫秒降到了40毫秒左右。第二步是数据库参数调优调整innodb_flush_log_at_trx_commit的取值从每次提交都刷盘改为每秒刷一次降低了fsync频率这是牺牲一点崩溃恢复的实时性换写性能要根据业务容忍度来定。第三步如果有条件把binlog和redo log分别放到不同物理设备上避免所有写压力挤在同一块盘上。这个案例最有价值的启发是iostat自己不会告诉你哪个进程导致的I/O高但它能极其准确地告诉你瓶颈在不在磁盘、是读还是写、是延迟问题还是吞吐问题。定位方向对了后面再上其他工具逐层收网就快很多。提示做现场诊断的时候把iostat和pidstat的输出一起记录下来。iostat给的是“磁盘怎么了”的宏观证据pidstat和iotop给的是“谁弄的”的微观证据两者一对定位速度翻倍。5. 常见问题与排查技巧实录5.1 %util超过100%正常吗新版本sysstat在NVMe等支持多队列的设备上%util可能显示超过100%比如140%、250%这并不代表设备出了问题也不代表它一定就瓶颈了。原因是%util的计算基于设备繁忙时间多队列设备可以并行处理多个请求总繁忙时间可能超过采样周期本身所以百分比会“虚高”。遇到%util超过100%的情况别被数字吓到重点仍然看await和aqu-sz。如果await低、队列不堆积说明设备虽然繁忙但响应很快性能还有余量如果await和队列同时攀升那不管%util是不是超过100%都要认真对待了。老内核或老sysstat版本对%util的处理方式不同有时即使设备很忙也只显示100%这就是上限了反而不容易区分。5.2 多块磁盘设备怎么快速找到瓶颈盘生产服务器往往挂着好几块盘sda、sdb、sdc、nvme0n1、nvme0n2铺满一屏。默认情况下iostat会把所有设备都列出来如果不加-z参数那些完全空闲的设备也会占用你的视线找重点盘全靠肉眼扫效率很低。我的习惯是加-z参数只显示有活动的设备这样空闲盘直接就过滤掉了。如果机器上的盘还是很多可以用watch -n 1 iostat -dxk 1 1做一个自动刷新的仪表盘每秒钟更新一次重点盯队列长度和%util最高的那几行。很多实际场景里只有一块盘在扛所有I/O其他盘很闲这种情况下瓶颈盘的定位几乎不需要额外思考。5.3 与vmstat、sar配合的综合排查思路iostat虽强但单独用也有盲区。比如内存不足导致swap换页这种I/O压力iostat也能看到但如果你不结合free和vmstat看就无法判断到底是什么原因触发的。我的综合排查顺序一般是这样先跑vmstat 1 5看整体状况看procs的r列、memory的swpd列、cpu的wa列形成第一印象。然后上iostat -dxk 1 5定位具体设备判断是哪个盘的读写压力大。再上pidstat -d或iotop定位具体的进程。比如有一次看到vmstat显示si和so一直在动换页很频繁同时iostat显示磁盘%util很高但await正常。这个组合说明问题根因是内存不够导致持续换页磁盘压力只是结果。如果只看iostat会误判成磁盘容量不够方向就错了。所以iostat的最佳定位是“第二棒”接在vmstat之后缩小范围而不是唯一的诊断依据。sar的用处在于回顾历史。如果你怀疑问题发生在半夜某个时间点但当时没有人在场敲命令可以直接看sar -d -f /var/log/sysstat/saXX来追溯那个小时的I/O情况判断是偶发现象还是持续存在。iostat管现场sar管历史vmstat管全局三者互补使用才完整。5.4 常见问题速查表现象可能原因下一步排查%iowait持续偏高设备%util不高文件系统锁、内存换页、NFS等网络存储查free、vmstat、dmesg单块盘%util接近100%await远大于svctm磁盘吞吐饱和写请求排队用pidstat -d定位进程考虑拆分I/O%util超过100%NVMe多队列设备采样周期内繁忙累计结合await和aqu-sz综合判断w_await高但r_await正常写路径拥堵可能是同步刷盘频繁查binlog、redo log落盘策略多块盘负载不均数据分布策略问题检查分区、LVM、RAID配置设备表出现dm-0等映射设备LVM或设备映射器逻辑设备用lsblk找到对应的物理盘另外单独提一个容易被忽略的细节iostat输出的第一行是系统当前时间这里的时间格式可能在有些系统上显示不出来因为时区配置或系统语言环境的问题。做监控记录时最好加上-t参数让每次采样都带时间戳这样事后整理数据时不会一头雾水。用iostat这几个月下来我最深的感受是它是个“锚点型”工具所有I/O问题最后都会在它这里得到确认或排除。很多人习惯一上来就找哪个进程在读写但不知道整个系统的I/O水位到底什么水平。先用iostat把大盘看明白再决定要不要继续挖进程这个顺序能省下大量时间。尤其是那种偶发性的卡顿等iotop抓出进程时往往已经错过了现场但iostat留下的采样记录能明确告诉你当时磁盘到底有没有异常。建议所有做Linux性能排查的人都把iostat -dxk练成肌肉记忆遇到可疑的系统变慢问题不要犹豫第一时间先跑一条看看。