1. 为什么需要监控磁盘 I/O从一次“查不出原因的卡顿”说起你有没有遇到过这种情况应用响应突然变慢CPU 和内存占用却都在正常范围内看日志也没报错可服务就是像陷在泥潭里一样。排查到最后才发现罪魁祸首是磁盘 I/O 到了瓶颈——数据读写的速度跟不上业务请求的速度整个系统被拖住了。在 Linux 服务器上磁盘 I/O 往往是比 CPU 和内存更容易被忽视的性能瓶颈。原因很简单CPU 和内存的监控工具多、指标直观出了问题一眼就能看出来而磁盘 I/O 的排查相对隐晦需要专门的工具摸清“谁在读写”“读写有多频繁”“写入的数据量到底多大”。我常用的两个工具就是 iotop 和 iostat一个定位罪魁祸首一个分析整体趋势配合起来基本能解决 90% 的磁盘性能排查问题。这篇内容写给运维工程师、后端开发以及所有需要面对 Linux 服务器性能问题的朋友。我尽量不讲空泛的理论直接说实际怎么用、输出怎么读、遇到问题时怎么从数据里找线索。毕竟排查性能问题和看病一样数据就是体检报告读得懂报告才能对症下药。2. 动手之前先搞懂几个核心指标2.1 I/O 不只是“读写速度”那么简单很多人刚接触磁盘监控时有个误区觉得只要盯着“传输速率”就够了。实际上磁盘 I/O 的性能由多个维度共同决定至少要看四个方面吞吐量Throughput单位时间内完成的数据传输量单位通常是 MB/s。这个指标决定的是“搬了多少货”。IOPSInput/Output Operations Per Second每秒完成的读/写操作次数。这个指标决定的是“装卸了多少次货”。I/O 延迟Latency一次 I/O 请求从发起到完成的时间单位通常是毫秒。这个指标决定的是“每单生意要谈多久”。I/O 队列深度Queue Depth等待处理的 I/O 请求数量。队列越深说明积压越严重。吞吐量和 IOPS 之间没有绝对的对应关系。一个系统如果以大量小文件读写为主IOPS 会很高但吞吐量一般如果以大文件顺序读写为主吞吐量会很高但 IOPS 可能一般。所以判断磁盘是否成为瓶颈不能只看单一指标。2.2 谁是“元凶”进程还是设备排查磁盘 I/O 问题最核心的问题有两个是哪块磁盘在忙是哪个进程在制造 I/O这两类信息恰好是两类工具的看家本领iostat 回答“设备层”的问题它能告诉你某块物理磁盘或分区是否繁忙、读写速率如何、平均 I/O 等待时间多长。站在全局视角看整体负载。iotop 回答“进程层”的问题它能实时列出每个进程的磁盘读写速率直接锁定是谁在“疯狂读写”磁盘。站在微观视角看具体个案。实战中最常用的组合拳是先用 iostat 确认整体负载异常再用 iotop 顺着异常的设备找到具体进程。下面我会把两个工具分别讲透最后再说怎么配合着用。3. iostat从全局把握磁盘健康状态3.1 安装与环境准备iostat 属于 sysstat 工具包绝大多数 Linux 发行版默认没装需要额外安装。经验之谈这是 Linux 运维机器上的“标配工具”建议直接装好别等排查问题时才想起来# Debian/Ubuntu 系列 sudo apt-get install -y sysstat # CentOS/RHEL 系列 sudo yum install -y sysstat安装之后建议执行一次iostat确认它能正常运行。有的发行版还会附带一个/etc/cron.d/sysstat的定时任务用来周期性地采集系统统计数据这对事后回溯很有帮助建议保留。3.2 基础用法先看整体再看细节不带参数执行iostat输出的是自系统启动以来的平均统计信息包含了 CPU 使用率和每块磁盘的统计。这个结果适合“快速体检”不适合定位当下的问题。实际排查中我更常用的命令是# 每2秒刷新一次连续输出5次以兆字节为单位显示 iostat -m 2 5这里-m让速率以 MB/s 为单位显示2 是刷新间隔秒数5 是输出次数。跑到第 2~3 次时数据已经比较有代表性了。如果要看更细的性能数据加上-x参数iostat -x -m 2 3-x表示 extended 模式会输出更多扩展指标。下面是模拟环境中的一次输出关键字段我做了注释说明Device rMB/s wMB/s aqu-sz %util sda 0.59 8.24 1.23 44.723.3 核心字段逐个拆解第一次看到 iostat 完整输出的人往往会对着满屏的英文缩写发呆。我按实战中最有用的程度排个序重点说明rMB/s / wMB/s或 rkB/s / wkB/s每秒读/写的数据量。这个值直接反映磁盘的数据吞吐压力。如果持续高位比如 SAS 盘持续超过 100MB/s 写基本可以认定磁盘在“满负荷搬运”。%util磁盘的繁忙程度百分比。注意这个值的含义和你想的不完全一样它不是“磁盘已用空间百分比”而是“磁盘处理 I/O 请求的时间占比”。这个值持续超过 80%磁盘等待队列就会开始堆积业务响应会明显变慢持续接近 100%磁盘基本已经饱和。aqu-sz平均队列长度等待处理的 I/O 请求平均数量。长时间大于 1 说明请求已经积压了。await平均等待时间I/O 请求从进入队列到完成处理的平均耗时单位毫秒。普通机械硬盘的 await 在 10~20 毫秒如果长期飙到 30 毫秒以上大概率是机械盘老化或者负载过高。SSD 这个值通常应在个位数超过 20 毫秒就要警惕了。r_await / w_await分别表示读请求和写请求的平均等待时间。有些场景读写差异很大——比如大量的顺序读和小块随机写混合你会看到 r_await 很低w_await 却反复飙高这说明写路径才是瓶颈。提示%util 的陷阱在于某些场景下它可能接近 100%但系统并不卡反过来某些磁盘有内部合并机制%util 不高但请求已经变慢。所以务必结合 await 和队列长度一起看别只盯着一个指标下结论。3.4 用 iostat 判断瓶颈方向的实用思路iostat 输出的绝对值本身意义有限关键在于观察趋势和比例关系。我常用的判断逻辑是这样的第一对比 rMB/s 和 wMB/s 的比值。如果读远大于写说明是读取密集型负载典型场景大量数据查询、日志扫描如果写远大于读说明是写入密集型负载典型场景数据库写入、日志落盘。知道了方向排查重点就能往对应方向倾斜。第二观察 %util 和 await 的联动关系。%util 高、await 也高说明磁盘真的扛不住了要么换硬件SSD 换 NVMe、机械盘换 SSD要么优化应用减少无效 I/O。%util 不高但 await 偏高问题可能在 I/O 调度策略或者单次请求的数据量太大可以考虑调整调度器或者应用层批量写入。第三用iostat的不同刷新次数捕捉“瞬时尖峰”。有些问题不是一直存在而是间歇性发作——比如每 10 分钟一次的定时任务引发的 I/O 风暴。遇到这种情况我会用iostat -x -m 1 30持续记录 30 秒拉长观察窗口寻找规律。4. iotop直接揪出“幕后黑手”4.1 安装和第一次运行iotop 的安装同样简单# Debian/Ubuntu 系列 sudo apt-get install -y iotop # CentOS/RHEL 系列 sudo yum install -y iotop需要特别提醒的是iotop 几乎都要用 root 权限运行因为它需要读取每个进程的 I/O 统计信息。普通用户运行大概率会报Netlink: Permission denied之类的错误这不是工具坏了是权限不足。首次运行建议用以下组合参数sudo iotop -o -P-oonly只显示正在产生 I/O 的进程。不加这个参数你会看到一大堆 I/O 为 0 的进程完全淹没有用信息。-Pprocesses以进程视图显示而不是默认的线程视图。线程视图信息更细但噪音也更大排查问题时先看进程层面。4.2 交互式命令高频快捷键iotop 启动后是类似 top 的全屏交互界面可以在运行时切换排序方式和过滤条件。我每次都会用到这几个快捷键p切换进程/线程视图。默认显示线程切到进程视图可以合并同一进程下所有线程的 I/O 数据。o切换只显示有 I/O 活动的进程。排查时一直保持开启状态。a切换累计 I/O 显示。默认显示的是瞬时速率开启后能看到每个进程自监控以来的累计读写量对判断“谁在长时间大量读写”很有帮助。箭头键上下移动光标选择具体进程查看详情。q退出。注意iotop 的交互性能和 top 没法比数据刷新相对缓慢也别指望它能像 top 一样流畅地频繁切换。实际使用中我通常让它跑个几十秒截取关键画面然后退出分析。4.3 读懂 iotop 的每列数据iotop 输出的列比较多但真正需要关注的是这几列TID/PRIO线程 ID 或进程 ID以及 I/O 优先级。优先级为be/4表示最佳努力级别、优先级 4数值越低优先级越高。DISK READ / DISK WRITE进程每秒的实际磁盘读取量和写入量单位默认是 B/s可以用-k或-m参数改成 KB/s 或 MB/s。SWAPIN进程发生交换swap操作时所占的时间比例。这个值不是 0 往往说明内存紧张进程正在内存和交换分区之间来回挪数据产生大量 I/O。IO进程等待 I/O 完成所花的时间占比。这个值高说明进程在等磁盘确实是 I/O 瓶颈拖了后腿。实战心法看这两个百分比要“结合起来”。IO高、SWAPIN也高说明问题是内存不足导致抖动优化方向是加内存或者调低进程内存占用IO高但SWAPIN接近 0说明是纯粹的磁盘性能不足或者读写模式不佳优化方向是磁盘硬件、I/O 调度或者应用读写方式。4.4 常见场景模拟用模拟写入来验证监控效果理论说再多不如现场演示一遍有说服力。我常用的验证方法是在运行 iotop 的同时用dd命令产生持续的写 I/O观察 iotop 能否实时捕获到对应进程。开一个终端执行sudo dd if/dev/zero of/tmp/test.bin bs1M count2048 convfdatasync这个命令会连续写入 2GB 数据强制刷盘。另一个终端运行sudo iotop -o -P -m你会看到dd或对应 shell这个任务出现在列表顶部DISK WRITE 一列从 0 快速攀升到每秒几百 MB。这就直观地验证了iotop 确实能实时追踪每个进程的磁盘写入。生产环境下可能干扰项很多比如缓存写入page cache会让应用看起来写得很慢但磁盘实际没动手。iotop 显示的是实际落到磁盘的数据量不是应用层发起的数据量这是它的优势——靠近真实物理 I/O 视图。5. 实战组合拳一张监控脚本全流程排查磁盘问题5.1 工具选型到底怎么定iostat 和 iotop 不是替代关系是互补关系。我画不出工具之间的层级归属就用一张简单的表格直观对比对比维度iostatiotop观测对象磁盘设备/分区进程/线程回答的核心问题“哪块盘在忙忙到什么程度”“哪个进程在读写读写量多大”历史回溯能力强有系统自带轮询统计弱只能看实时状态权限要求普通用户可读多数指标基本需要 root运行场景持续监控脚本、事后分析临时跟踪、锁定元凶注意想要追溯异常发生时刻的历史数据iostat 更合适——很多发行版通过 sysstat 自带的 cron 任务周期采集数据你可以去/var/log/sysstat/下面翻历史记录。iotop 只能看当下过去了就过去了。5.2 排查思路从“现象”到“根因”的四步法一段高效的排查流程比单个命令重要得多。以“服务响应变慢”这个现象为例我推荐的排查链路是第一步用常规命令确认方向。先跑top看一眼整体负载如果发现较高的waI/O wait百分比基本就可以把嫌疑锁定在磁盘 I/O 上了。第二步用 iostat 确认设备层现状。执行iostat -x -m 2 5重点观察哪块盘的 %util 或 await 异常。如果多块盘同时异常考虑是否存在共享存储资源如同一块 RAID 卡的争抢如果只有一块盘异常问题大概率聚焦在这块盘承载的业务上。第三步用 iotop 锁定进程元凶。执行sudo iotop -o -P -m -b -n 10其中-b是批量模式不进入交互界面直接往屏幕输出-n 10是采样 10 次自动退出。这样能在无人值守的情况下拿到关键数据比较适合在终端窗口里滚一屏日志。第四步结合业务上下文判断“是病不是病”。如果是数据库的定期备份任务、批处理任务导致的周期性 I/O 高峰只要高峰期间业务能承受就不需要干预如果是持续性的高 I/O 且伴随服务响应恶化才需要进一步优化。# 四步法中用到的核心命令汇总 top # 第一步看 wa 占比 iostat -x -m 2 5 # 第二步看设备级指标 sudo iotop -o -P -m -b -n 10 # 第三步锁定进程 # 第四步结合业务场景分析5.3 一个完整的模拟案例日志服务引发的磁盘风暴我把排查流程放到一个虚拟场景里走一遍这样更好理解。假设某公司的日志服务出现响应变慢登录服务器后依次执行top看到wa指标在 35% 以上说明 CPU 大量时间在等磁盘。执行iostat -x -m 2 3输出数据指向/dev/sdb这块盘%util 长期在 85%~95% 之间wMB/s 在 15MB/s 上下徘徊队列长度稳定在 2.5 左右。基本可以判定写压力大磁盘承载接近饱和。接着用 iotop 追踪sudo iotop -o -P -m -b -n 5输出中最醒目的是一个日志采集进程DISK WRITE 一直在 12MB/s 左右。进一步查业务配置发现它开启了 debug 级别的日志输出并且每条日志附带大量上下文信息同一秒内产生了几千行日志。把日志级别调回 info关掉冗余字段后磁盘 %util 立刻降到 30% 以内服务响应恢复。这个案例有个很重要的启示磁盘问题的根源经常不是磁盘本身而是上层应用“制造了过多不必要的 I/O”。优化 I/O 数量往往比换硬件更立竿见影。6. 常见问题与排查技巧实录6.1 iotop 输出内容为空或信息不完整新手经常遇到的问题就是运行 iotop 后进程列表“一片寂静”。多数原因是权限不足——不用 root 运行、或用 sudo 但当前用户不在sudo组都会导致无法读取内核 I/O 统计。另一个可能原因是-o生效且确实没有活跃 I/O这时可以去掉-o参数多观察几秒。6.2 iostat 输出显示异常大的换算值iostat 默认按块block显示如果你看到数字特别大先别慌试试-m参数换算成 MB。还有个坑是某些云主机上的虚拟磁盘驱动显示的数据单位和物理盘不同用同一个标准换算可能造成误判。面对云主机时我更关注 await、%util 这类比率指标它们受单位差异影响更小。6.3 高 I/O 不是“病”如何判断要不要处理最容易被忽略的经验是磁盘利用率高不等于有问题。像数据仓库的批量导入、全文索引的定期重建这些任务跑起来时磁盘基本会打满但若业务可接受就不算故障。真正要警惕的是“业务高峰期 I/O 打满且任务响应指标恶化”——这才是需要介入的信号。判断是否处理可以问自己三个问题I/O 峰值是否影响核心业务响应峰值是否有规律、能否避开业务高峰优化后能否降低单位请求的磁盘成本任何一条答案为“是”都值得深入优化。6.4 排查的进阶技巧双向验证排查中避免“单工具误判”的最好办法是交叉验证。比如 iotop 显示进程 A 在大量写磁盘那么 iostat 对应磁盘的 wMB/s 应该同步抬升如果 iotop 说看到某进程在疯狂读那这块盘的 r/s 和 rMB/s 也应该有对应表现。数据对不上时基本可以怀疑是数据采集或权限问题而不是磁盘真的在忙。这招我在实际排查中用过很多次能省去不少瞎猜的时间。7. 最后的经验之谈iostat 和 iotop 我已经用了很多年如果总结成一句话先全局后局部先设备后进程先指标后结论。这个顺序能帮你把“系统变慢”这样模糊的问题逐步拆解成“某块盘饱和→某个进程过量读写→某类业务产生垃圾 I/O”这样的清晰链条。一个小技巧是在出问题的服务器上提前配置好 sysstat 的历史采集日常保留/var/log/sysstat/下的历史数据。等下次性能问题爆发时你甚至可以翻出问题发生时刻的 iostat 历史记录做复盘这在事后根本来不及人工盯盘的情况下尤其有价值。遇到磁盘问题不要一上来就想“换 SSD”。先看看是不是应用在大量做无效读写再来决定是改代码还是改硬件。工具只能帮你看见问题解决问题始终需要结合业务逻辑来判断——这一行干得久了你会发现工具学起来快判断力的积累才真正需要时间。