IO

iotop 把任务级内核统计接入系统整体的存储调查，可以帮助发现报告大量 IO 或等待的任务，但这两种观察并不相同。被其他工作阻塞的任务，可能是受影响者，而不是争用的来源。内核计数器也不为每种文件系统、缓存与存储层提供完美归因，不能把一个列表直接当成责任判决。 把 iotop 与设备指标、应用延迟放在一起看。活跃写入者或较高等待值，单独都不足以证明存储瓶颈。先比较同一时段，再决定检查哪个组件；两个命令的输出可以形成线索，却不会自动结束调查。应明确自己看到的是工作量、等待时间，还是实际设备完成的操作。 逐个进程的计数器 先核对安装的实现与版本。所引用的 iotop-c 已在主进程行中汇总线程活动；-P 只是隐藏单独的线程行。其他变体应核对各自手册，不能把显示选项误写成首次发生汇总。-o 根据观察到的 IO 活动过滤，不会判断工作是否有害。读写字节速率与 IO 等待百分比单位不同，不能把它们当作同一种消耗排名，也不能只凭一列高低决定是否应终止进程。 Linux 的 read_bytes 统计存储层读取，缓存命中的读取不一定产生这类字节。write_bytes 在页面变脏时记账，不一定等到设备完成写入；取消写入与稍后的回写，会让任务总量和设备吞吐不同。延迟统计记录任务等待，包括同步块 IO 等待；CPU iowait 是另一种整体指标，不能作为可靠的逐任务归责依据。页面缓存中的活动、进程等待和设备忙碌，需要分别解释。 看到谁在扫盘 明确选择排序列，并观察足够时间，区分持续工作和短促突发。写入速率高可能来自预期的备份、索引构建或日志任务。修改调度、限额之前，要关联进程归属、应用角色与当时业务。排名靠前只说明值得进一步检查，不会直接告诉你应轮转日志、迁移任务还是终止进程，正常的批处理也可能占据榜首。 在正确的 PID 命名空间中解析任务，并确认该标识仍指向预期进程。命令行、父子关系与打开文件能够提供上下文，但打开某个文件不证明全部写入都去了那里。两次读取之间 PID 可能复用，陈旧号码可能已经属于无关任务。容器内外看到的号码也可能不同，必须把身份与观察范围一同记录，避免把一个范围中的统计匹配到另一个范围中的进程。 先看再动 观察本身有成本与访问要求。进一步的系统调用追踪可能扰动进程并暴露参数，需要另外获准且范围明确的调查。追加标志属于打开文件时的设置，不是每次 write 系统调用携带的标志。不能把虚构的吞吐、打开文件与追踪输出组合成一次已测得的诊断，也不能看到文件存在就推断写入路径已被证明。 记录基线条件：工具实现、间隔、进程或线程模式、是否累计，以及可比较的业务负载。按文档默认的一秒间隔，-b -n 60 大约是一分钟，不是五分钟，还要考虑启动与首份报告。设备 await 包含排队与服务时间；接近百分之百的利用率，并不能在所有并行 SSD 或 RAID 上证明吞吐已经饱和。 ...

blk-mq 提供 CPU 或节点本地的软件暂存队列，以及硬件派发队列。请求可以在派发前经过调度和合并，但驱动与设备行为也会影响实际服务。软件提交顺序不保证完成顺序。调度器能够影响竞争请求进入设备的方式，却不控制整个存储栈后续的每一项决定。分析时应分别记录提交、派发与完成，避免从一条队列箭头推出设备执行的完整时间线。 在旋转介质上，改善请求局部性可以减少磁头移动。闪存没有机械寻道成本，但合并、并行度、排队和仲裁仍会影响性能。高效排序与公平服务回答不同问题，都不能给出普遍适用的调度器排名。应先确认当前内核与设备实际提供哪些选项，再测量相关负载，不要因为设备名称包含 NVMe 就把所有队列政策的成本与收益都当成零。 磁头才是预算 7200 RPM 下半圈约为 4.17 ms，可作为理想化的平均旋转等待。传输与寻道成本还依赖设备和负载。原文给出 2000 个请求、67907411 与 99977 条磁道，以及 91 与 231 IOPS，但没有提供生成夹具或保留测量。这些数字只能作为未经核验的原文声称，不能写成已经测得的 Linux 调度器结果，更不能用倍数直接推算生产设备的容量。 对一组虚构磁道位置排序，可以说明磁头行程有可能缩短，但没有经过验证的设备模型或测量，就不能建立 IOPS 收益。此前的寻道百分比和约 40 ms 的 NVMe 总耗时，也有同样的证据缺口。图中更短的路径因此只表示定性关系，不是延迟预测。实际比较应保留请求序列、模型假设、设备信息与原始输出，才能判断差异是否来自调度。 每种调度器是干什么的 none 不增加调度器重排，但不承诺全局先到先完成。mq-deadline 结合扇区顺序和批次之间的到期检查，fifo_batch 限制每批数量；这些政策影响派发，并不保证端到端完成期限。kyber 通过限流尝试达到读取与同步写入的目标延迟，目标值不是每个请求都必然达标的证明。设备处理时间与后续排队仍然存在，不能把参数名当成业务延迟服务承诺。 bfq 提供按权重的服务分配和低延迟启发式，带宽或时间分配取决于配置与条件。空转可以帮助服务保证，却也可能降低内部有队列设备的吞吐，必须核对内核支持和实际设置。/sys/block//queue/scheduler 中带方括号的名称表示当前选项；修改它是运维动作，需要已授权的设备和可撤销测试方案。不能只看到一个名称，就推定持久设置、隔离效果或吞吐收益已经建立。 公平与排序是两个问题 90/10 的请求发出比例，不能直接建立服务份额或平均等待位置。原文的 0.099、1901 与 0.5 没有保留夹具作为依据。在持续有积压的简化模型里，相等权重可以说明分享概念，但真实结果还取决于需求、请求大小、优先级和调度设置。应分别比较收到的服务、应用延迟与请求到达数量，不能把不同分母下的比例当成同一个指标，更不能保证轻客户端永远取得一半吞吐。 ...