服务器I/O性能直接决定了业务响应速度与系统稳定性，查看服务器I/O状况的核心结论是：必须建立以工具为基础、以指标为核心的监控体系，优先排查磁盘读写速率（%util）与IOPS，并结合进程定位瓶颈源头，单一的命令往往只能窥探全貌的一角，只有组合使用iostat、iotop等工具，才能精准定位问题，以下将从核心指标、工具实战、瓶颈定位三个层级展开详细论证。
核心指标：读懂I/O性能的关键数据
在执行操作之前，必须先理解衡量I/O性能的四个核心维度，这四个指标是判断服务器I/O怎么察看的基础标准。
-
IOPS（每秒读写次数）
这是衡量磁盘性能最直观的指标，它代表每秒能处理的请求数量，对于随机读写频繁的数据库业务，IOPS是核心瓶颈，通常SATA硬盘在80-100左右,SSD可达数万。 -
吞吐量
指每秒读写的数据量，单位通常为MB/s，对于视频流、备份归档等顺序读写业务,吞吐量是首要关注点。 -
利用率（%util）
这是判断磁盘是否饱和的最关键指标，当%util接近100%时，说明磁盘I/O队列已满，此时应用层会明显感觉到卡顿，但需注意，RAID阵列或SSD由于并行处理能力，即使%util较高，可能仍有处理能力,需结合其他指标综合判断。 -
平均等待时间
包括await和svctm，await是应用层感知到的总等待时间，svctm是磁盘硬件处理时间。如果await远大于svctm，说明I/O请求在队列中排队时间过长，磁盘压力过大或存在性能瓶颈。
工具实战：多维度监控I/O状态
掌握了指标后，需要通过专业工具获取数据，针对不同场景，需使用不同的工具组合，这是解决服务器I/O怎么察看的具体执行路径。
iostat：系统级I/O监控首选
iostat是sysstat包的一部分，是查看服务器I/O最常用的工具。
- 常用命令：
iostat -x -k 1 10 - 参数解析：
-x显示详细扩展信息，-k以KB为单位，1表示每秒刷新一次，10表示刷新10次。 - 重点关注：
- %util：磁盘繁忙程度。
- await：平均I/O等待时间。
- r/s, w/s：每秒读写次数,即IOPS。
- rkB/s, wkB/s：读写吞吐量。
如果发现某块磁盘的%util持续高于90%，且await显著升高，基本可判定该磁盘存在I/O瓶颈。
iotop：进程级I/O定位利器
当发现磁盘繁忙时，必须找出是哪个进程在“作祟”，iotop类似于top命令，专门用于监控进程I/O使用情况。
- 常用命令：
iotop -oP - 参数解析：
-o只显示有I/O操作的进程，-P只显示进程而不显示线程。 - 结果分析：界面会实时显示进程的读写速率。通过DISK READ和DISK WRITE列，可以迅速锁定占用I/O资源最高的进程ID（PID）,从而进行针对性优化或停止进程。
vmstat：全局系统资源视角
vmstat虽主要查看内存和CPU，但其io区域的bi（块设备读入）和bo（块设备写出）能提供系统整体I/O流量概览。
- 常用命令：
vmstat 1 - 分析逻辑：如果bi和bo长期维持高位，且wa（等待I/O的CPU时间百分比）较高，说明I/O已经影响到了CPU性能,系统整体处于重负载状态。
dstat：全能监控替代者
dstat集成了iostat、vmstat等多款工具的优点，能同时显示CPU、磁盘、网络、分页等数据，且输出颜色区分明显,适合实时监控。
- 常用命令：
dstat -cdlmn
瓶颈定位与优化策略
通过上述工具获取数据后，如何形成独立的判断并解决问题？这需要结合业务场景进行深度分析。
-
区分随机与顺序读写
如果iostat显示r/s、w/s很高，但rkB/s、wkB/s很低，说明是随机读写为主（如数据库小事务），此时应关注IOPS上限，考虑更换SSD或优化数据库索引，反之，如果吞吐量高但IOPS低，则是顺序读写（如日志写入）,应关注带宽限制。
-
排查RAID卡与文件系统
有时候硬件层面的瓶颈比磁盘本身更隐蔽。检查RAID卡的BBU（电池备份单元）状态和缓存策略，Write Back策略能大幅提升写性能，而Write Through则会导致性能骤降，文件系统的挂载参数（如noatime）也会显著影响I/O性能。 -
内核参数调优
Linux内核的I/O调度算法对性能影响巨大。- CFQ（完全公平队列）：适合桌面及多媒体应用,保证公平。
- Deadline：适合数据库业务，保证请求在截止时间前完成,减少延迟。
- Noop：适合SSD或自带控制器的存储设备，简单高效。
可通过cat /sys/block/sda/queue/scheduler查看当前调度器,并根据业务类型动态修改。
-
应用层优化
工具只能发现问题，解决问题往往在应用层，如果是日志打印过频导致I/O高，可调整日志级别或引入异步日志框架；如果是数据库全表扫描导致读I/O飙升,则需优化SQL语句或添加索引。
相关问答模块
问：iostat命令中，await值很高但%util很低，这是什么原因？
答：这种情况通常意味着I/O请求虽然不多，但每个请求的处理时间都很长，可能原因包括：磁盘存在坏道导致读取重试、网络存储（NAS/SAN）的网络延迟过高、或者是RAID卡正在重构数据导致响应变慢，此时不能仅看利用率,需检查硬件健康状态或网络链路质量。
问：服务器I/O很高，但使用top命令查看CPU的wa（等待I/O）值却不高，为什么？
答：这说明I/O压力主要在磁盘设备端，而未传导至CPU，常见于异步I/O（AIO）场景，例如应用程序使用了异步写入方式，数据写入Page Cache后应用就返回了，后续由内核线程异步刷盘，此时CPU不需要等待I/O完成，因此wa值不高，但磁盘实际负载很重。
涵盖了服务器I/O监控的核心逻辑与实操方案，如果您在实际操作中遇到特殊的I/O瓶颈场景,欢迎在评论区留言讨论。
首发原创文章，作者：世雄 - 原生数据库架构专家，如若转载，请注明出处：https://idctop.com/article/141001.html
