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。这个指标决定的是“搬了多少货”。IOPS（Input/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-o（only）：只显示正在产生 I/O 的进程。不加这个参数，你会看到一大堆 I/O 为 0 的进程，完全淹没有用信息。-P（processes）：以进程视图显示，而不是默认的线程视图。线程视图信息更细但噪音也更大，排查问题时先看进程层面。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 bs=1M count=2048 conv=fdatasync这个命令会连续写入 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看一眼整体负载，如果发现较高的wa（I/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”。先看看是不是应用在大量做无效读写，再来决定是改代码还是改硬件。工具只能帮你看见问题，解决问题始终需要结合业务逻辑来判断——这一行干得久了你会发现，工具学起来快，判断力的积累才真正需要时间。
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。这个指标决定的是“搬了多少货”。IOPS（Input/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-o（only）：只显示正在产生 I/O 的进程。不加这个参数，你会看到一大堆 I/O 为 0 的进程，完全淹没有用信息。-P（processes）：以进程视图显示，而不是默认的线程视图。线程视图信息更细但噪音也更大，排查问题时先看进程层面。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 bs=1M count=2048 conv=fdatasync这个命令会连续写入 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看一眼整体负载，如果发现较高的wa（I/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”。先看看是不是应用在大量做无效读写，再来决定是改代码还是改硬件。工具只能帮你看见问题，解决问题始终需要结合业务逻辑来判断——这一行干得久了你会发现，工具学起来快，判断力的积累才真正需要时间。