<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Iotop · XB 现场笔记</title><link>https://www.xbcatm.com/zh/tags/iotop/</link><description>基于 HTTP、DNS、TLS、Caddy、SSH、发布与恢复的可复现运维现场笔记。</description><generator>Hugo</generator><language>zh-CN</language><atom:link href="https://www.xbcatm.com/zh/tags/iotop/index.xml" rel="self" type="application/rss+xml"/><item><title>iotop 能看出是哪个进程在烧磁盘</title><link>https://www.xbcatm.com/zh/posts/linux-iotop-io-waiter/</link><pubDate>Wed, 15 Mar 2028 00:00:00 +0000</pubDate><guid>https://www.xbcatm.com/zh/posts/linux-iotop-io-waiter/</guid><description>iotop 通过读取内核统计观察每个进程的 IO，于是能把忙碌的磁盘怪到具体某个 pid 头上。</description><content:encoded>&lt;p&gt;磁盘突然飙升却找不到明显的写入者时，iotop 把吞吐直接指回那个在捣乱的进程。系统级工具只给症状——await 高、util 打满——不给嫌疑人：五十个进程共享磁盘，平均值平等地怪每一个。终结调查的永远是按进程的问题——谁、多少、何时开始——iotop 从内核计数器实时回答，应用藏都没处藏。&lt;/p&gt;
&lt;p&gt;把它放在系统级视图旁边，而不是代替。iostat 或 vmstat 说磁盘是瓶颈，iotop 点名是谁造成的。两者合起来把存储悬案压成两条命令：确认资源，锁定消费者。&lt;/p&gt;
&lt;h2 id="逐个进程的计数器"&gt;逐个进程的计数器&lt;/h2&gt;
&lt;p&gt;iotop 从内核读每个进程的 IO，于是实时读写速率能对应到一个 pid，而不是一个说不清来源的负载均值。加 &lt;code&gt;-o&lt;/code&gt; 只显示真正在做 IO 的进程，一眼看清。默认视图读写分开，还带 swap-in 百分比，把真吃磁盘的和仅仅在场的分开——DISK READ 高、写零的是在扫，写高的在产； throttle、迁移还是杀，取决于这个区分。&lt;/p&gt;
&lt;p&gt;注意计数器量的到底是什么：穿过 IO 层的按进程字节，含还没落盘的缓冲写。进程写速率巨大、磁盘看着却闲（页缓存吸收），或速率平平、磁盘打满（大量小同步写），都可能。iotop 跟设备 util 一起读：进程侧定罪加设备侧饱和才是完整画面，任一半单独都误导。&lt;/p&gt;
&lt;h2 id="看到谁在扫盘"&gt;看到谁在扫盘&lt;/h2&gt;
&lt;p&gt;按带宽排序，那个罪魁就现形了，无论是日志囤积、索引器还是失控备份。跟住这个 pid，就能定位到确切的进程（往往还有文件），再动手不迟。惯犯名单：debug 级别没轮转的日志、排在高峰的重建索引、同盘读写备份、坏镜像上循环解包的容器层。修法各不同——轮转、改期、分开、清理——杀进程治标，病因明天定时再来。&lt;/p&gt;
&lt;p&gt;动手前把 pid 解析到完整上下文：命令行、工作目录、lsof 看开文件、父进程。一个烧写的 java 进程背后可能是一个 PID 命名空间里的十个应用；修要修对那一个。先定罪后动手——每个以遗憾收场的存储 war story 都跳过了第一步。&lt;/p&gt;
&lt;h2 id="先看再动"&gt;先看再动&lt;/h2&gt;
&lt;p&gt;iotop 只观察、不改变任何东西，所以你可以在决定节制、迁移或停掉之前先把元凶查清楚。再配 strace 或 lsof 打到这个 pid，把文件和系统调用一并钉死。组合是决定性的：iotop 说 18412 进程写 400MB/s，lsof 说写进一个膨胀的日志文件，strace 显示 4KB 的 O_APPEND 写——诊断完毕；修法（日志级别、轮转、异步 appender）不言自明，不用开会争。&lt;/p&gt;
&lt;p&gt;健康时录基线，故障时对比才有意义。平时某天 &lt;code&gt;iotop -b -n 60&lt;/code&gt; 落文件五分钟，就是这台机器的&amp;quot;正常&amp;quot;数字：平时谁领跑、多少速率算寻常。没有它，每次 spike 都像史无前例；有了它，多数 incident 几秒归类：&amp;ldquo;又是 indexer，提前一小时&amp;rdquo;。
把 iotop 批输出和系统监控同一时段的曲线放一起看，进程侧和设备侧互相印证，结论才站得住。单看任何一边，都可能把相关当因果。
告警阈值按基线设，而不是拍脑袋，基线之外的 spike 才值得半夜起床。
把 Top 写入者的变化趋势也画出来，渐变比突变更早暴露问题。&lt;/p&gt;
&lt;p&gt;基线文件要标清楚采集条件：采集时段、业务负载水位、iotop 的采样间隔与累计方式，否则下次对比就是拿苹果比橙子。建议每周固定一个低峰窗口复采一次，覆盖掉业务自然增长带来的漂移；复采后把新旧两份排名并排 diff，只看名次变化超过三位的进程，逐个确认是业务上线还是异常冒头，再决定跟进还是放行。确认结论也要回写基线备注。&lt;/p&gt;
&lt;h2 id="坏掉的样子"&gt;坏掉的样子&lt;/h2&gt;
&lt;p&gt;最经典的元故障是权限盲：没特权跑，iotop 进程细节全问号，别用户的进程直接不显示——而真凶恰跑在别用户下，隐形到底。一开始就带够特权（root 或对应 capabilities），不然工具开脱的恰是你看不见的进程。无特权 iotop &amp;ldquo;什么都没查到&amp;rdquo;，只代表你自己的进程没事。&lt;/p&gt;
&lt;p&gt;第二种是突发 IO 的采样幻觉：一分钟暴力一秒的进程，5 秒平均看着无辜，1 秒平均看着有罪，反之亦然。数字和症状对不上就换 delay 档；&amp;ldquo;过去一小时谁伤的盘&amp;quot;问累计总量（&lt;code&gt;-a&lt;/code&gt;）不问瞬时速率。聚合方式对，问题才对；默认聚合只答它自己假设的那个问题。&lt;/p&gt;
&lt;h2 id="快速验证"&gt;快速验证&lt;/h2&gt;
&lt;p&gt;非交互地抓谁在做 IO，带上下文：&lt;/p&gt;
&lt;pre tabindex="0"&gt;&lt;code&gt;iotop -b -n 5 -o -d 2 | head -n 30
pid=$(iotop -b -n 1 -o | awk &amp;#39;NR&amp;gt;5 {print $1}&amp;#39; | head -n 1); ls -l /proc/$pid/exe; cat /proc/$pid/cmdline | tr &amp;#39;\0&amp;#39; &amp;#39; &amp;#39;
iostat -x 1 3 | grep -E &amp;#34;Device|sd|nvme&amp;#34;
&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;batch 抓排名不占终端，pid 解析点名头号写者的二进制，iostat 确认设备侧真打满。&lt;/p&gt;
&lt;h2 id="延伸阅读"&gt;延伸阅读&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href="https://www.xbcatm.com/zh/notes/certificate-expiry-is-a-date-not-a-dashboard-color/"&gt;证书过期是一个日期，而不是仪表盘上的颜色&lt;/a&gt;&lt;/li&gt;
&lt;li&gt;&lt;a href="https://www.xbcatm.com/zh/notes/head-should-describe-the-same-representation-as-get/"&gt;HEAD 应描述与 GET 相同的表示&lt;/a&gt;&lt;/li&gt;
&lt;/ul&gt;
&lt;h2 id="来源"&gt;来源&lt;/h2&gt;
&lt;ul&gt;
&lt;li&gt;&lt;a href="https://man7.org/linux/man-pages/man8/iotop.8.html"&gt;iotop 手册&lt;/a&gt;，iotop 官方参考，已核验 2026-06-01。&lt;/li&gt;
&lt;li&gt;&lt;a href="https://man7.org/linux/man-pages/man8/vmstat.8.html"&gt;vmstat 手册&lt;/a&gt;，说明系统级 CPU 与 IO 等待报告，已核验 2026-09-05。&lt;/li&gt;
&lt;/ul&gt;</content:encoded></item></channel></rss>