服务器I/O利用率查询，核心答案是：主流Linux系统用<iostat命令，Windows系统用性能监视器，云服务器直接用云控制台监控面板，这是运维排查、性能评估的第一步，也是最可靠的一步。
linux服务器io占用率高的排查方法
很多朋友遇到服务器变卡、数据库响应慢，第一反应是看CPU，结果CPU占用率不高，问题却一直存在，这时候就要把目光转向I/O层面了。
iostat命令：查看I/O利用率的根基
iostat是sysstat工具包里的核心命令,绝大多数Linux发行版都自带，没装的话，用包管理器装一下即可，比如CentOS执行yum install sysstat，Ubuntu执行apt install sysstat。
基本用法如下：
iostat -x 1这个命令每隔1秒输出一次扩展统计信息,需要关注的是%util这一列，它表示磁盘处理I/O请求的繁忙程度，行业共识是%util超过80%基本可以判定磁盘压力较大，但要注意，某些固态硬盘即使%util很高，实际响应速度依然不差。
另外要看的指标还有：
- r/s和w/s：每秒读写请求次数
- rkB/s和wkB/s：每秒读写数据量
- await：I/O请求平均等待时间，包含排队和服务时间
- svctm：I/O请求平均服务时间
avg-cpu: %user %nice %system %iowait %steal %idle
2.10 0.00 0.80 15.30 0.00 81.80
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %utilvda 0.00 0.50 0.10 3.20 4.80 14.90 11.90 0.01 2.00 1.00 2.10 0.40 15.30
上面的输出里还有个%iowait，它代表CPU等待I/O完成的时间占比，这个值长期偏高，说明CPU在等磁盘，系统瓶颈基本可以锁定在I/O上了。
定位占用I/O的具体进程
iostat只能告诉你磁盘整体忙不忙,但查不清是哪个进程在捣乱，这时候用pidstat来按进程维度排查。
pidstat -d 1输出里能看到每个进程的读写速率和I/O等待占比，假如发现某个Java进程的KB_READ和KB_WRITE特别夸张，那就接着用lsof查看它打开了哪些文件。
lsof -p PID再看这个进程的读写模式,就能判断是不是日志写入太频繁，或者数据库文件所在盘读写竞争太激烈。
iotop实时监控：像看top一样看I/O
iotop对运维人员来说更直观,它跟top命令的界面风格类似。
iotop -o-o参数只显示有I/O操作的进程，按实际读写速度排序，排查时盯住IO>列，哪个进程数值高，它就是当前占用I/O的主要来源。
服务器io利用率过高怎么查
iostat -x 1
多数情况下,I/O利用率过高不是某一个瞬间的问题，而是持续性的负载累积，查六七月份线上数据库卡顿的问题，用上面的命令看%util和await，基本一抓一个准。
从等待时间判断是负载过高还是硬件瓶颈
当await数值很高但svctm很低,说明请求大量在排队，本质是磁盘处理能力跟不上需求，负载大于容量，这时候加硬件或者把部分读写切到缓存层更实用，如果await和svctm数值都高，且%util接近100%，问题很可能出在磁盘本身的随机读写能力上，长期高负载场景考虑换成NVMe固态硬盘是常见解法。
抓取高I/O时段的具体场景
排查服务器io利用率过高,最好配合定时任务记录高峰时段的数据，例如用crontab每5分钟执行一次iostat并追加到日志文件，问题复现后再去回溯，能省下很多靠运气等问题的精力。
/5 iostat -x 1 1 >> /var/log/io_stat.log
云服务器用户专用排查路径
如果用的是简米云、酷番云这类公有云，直接登录云监控控制台查看磁盘读写IOPS和吞吐量曲线最直接，图形化界面还能设告警阈值，不用反复敲命令，自从接入了云监控告警，磁盘性能异常这件事基本能做到提前感知。
windows服务器磁盘io性能监控
Windows环境没有iostat,但有图形化工具，Windows Server系统自带性能监视器，通过运行perfmon打开。
性能监视器添加计数器步骤
打开perfmon后,右键”性能监视器”选择”添加计数器”，在可用计数器列表里找到PhysicalDisk，添加以下指标：
- % Disk Time：磁盘处理请求的时间占比
- Current Disk Queue Length：当前磁盘请求队列长度
- Avg. Disk sec/Read：平均每次读取耗时
- Avg. Disk sec/Write：平均每次写入耗时
perfmon
Get-Counter "\PhysicalDisk(_Total)\% Disk Time"
Windows平台如果找不到哪个进程在大量读写磁盘,打开”任务管理器”切到”性能”标签页，再点底部”打开资源监视器”，在”磁盘”选项卡里能按进程查看读写字节数，定位占用源非常直观。
几个关键I/O指标的内行解读
看懂指标是查I/O利用率的前提，但只看单个数值容易误判。
%util和await的真实含义
%util接近100%意味着磁盘在绝大多数时间都有请求在处理，不代表磁盘已经坏了，只说明压力很大，判断是不是真瓶颈，还要结合排队时长，排队时长短时间内持续飙升，磁盘性能确已吃紧。
IOPS和吞吐量的取舍
IOPS代表每秒读写次数,吞吐量代表每秒传输数据量，小文件随机读写看IOPS，大文件顺序读写看吞吐量，两者不可混为一谈，查I/O利用率时如果只看总吞吐量，很容易忽略掉随机小IO高延迟的问题。
队列长度的影响
Average Queue Length持续大于磁盘控制器队列深度的2倍时，性能会明显恶化，排查时队列长度指标和%util结合来看，能更真实反映磁盘压力。
找出问题之后的I/O优化方向
I/O利用率找到问题根源之后，收尾工作比查问题本身更考验基本功。
写密集场景的落地方案
如果确认是大量日志写入导致I/O高，先把日志级别调低，再考虑把日志目录放到独立的磁盘分区上，写入频率极高的业务，用内存盘或Redis做缓冲再异步落盘是常见做法。
数据库I/O瓶颈的处理
数据库文件所在的盘I/O利用率高，优先检查慢查询，很多慢SQL会导致全表扫描，产生大量随机读，索引优化之后，读请求数量可能直接下降一个量级，之后的方案按成本从低到高排队：调整缓冲池大小、读写分离、换SSD，综合这些调整方案的整体费用，自建数据库调优的成本主要集中在DBA人力时间上，云数据库则可以直接升配IOPS容量，明码标价，两者预算思路完全不同。
文件系统层面的技巧
挂载参数里加上noatime能减少访问时间戳的写入,对读多写少的业务有明显帮助，使用ext4的delayalloc或xfs的延迟分配特性，也能减少小块写入次数，降低I/O压力。
服务器I/O利用率查询常见问题
iostat中%util已经达到100%了，是不是一定要换硬件？
不一定,先检查有没有进程在做全盘扫描、备份任务、日志清理等操作，排除这类瞬时大流量之后，再结合await和队列长度判断，假设只是周期性的大任务导致短暂达到100%，业务高峰期错开这类任务即可，没必要直接升级硬件。
云主机控制台显示的I/O监控数值和iostat不一致，以哪个为准？
两者统计口径不同,云监控通常统计的是底层宿主机视角的物理磁盘数据，iostat统计的是虚拟机内看到的虚拟磁盘数据，数值存在差异属正常现象，排查业务自身性能问题参考iostat，和云厂商工单沟通则用云监控的数据。
I/O利用率长期处于低数值，但业务依然卡顿，问题出在哪？
这种情况大概率不是磁盘容量层面的瓶颈,检查文件系统碎片化、磁盘坏道、RAID组降级运行状态，极少数场景跟内核I/O调度器配置有关，调整调度算法后再观察，还有一个容易忽略的点，网络文件系统NFS的I/O统计默认不在本地iostat里显示，挂载NFS的业务需要单独查看NFS服务端的指标。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/795763.html
