MongoDB 4.4 PSA集群Secondary节点磁盘利用率异常过高求助

• 监控指标计算逻辑偏差
  你使用的asPercent(perSecond(*.*.diskio.io_time),1000)计算方式存在统计维度问题：io_time是设备有I/O请求排队的毫秒数，perSecond取每秒累计排队时间后转成百分比，这个值反映的是I/O排队时间占比，并非实际磁盘利用率（通常指磁盘处于繁忙状态的时间占比）。Secondary节点的复制操作I/O请求更零散，队列等待时间更长，会导致该计算值被放大，而iotop观测到的是进程实际磁盘繁忙占比，二者统计逻辑不同，这是最核心的原因。

• 主从节点I/O模式差异
  Primary节点的批量写入、更新属于顺序/批量I/O，磁盘处理效率高，排队时间短；而Secondary节点应用oplog时是单条回放操作，属于随机I/O。随机I/O的队列等待时间远高于批量顺序I/O，会拉高io_time指标，但实际磁盘繁忙时间（iotop的IO%）并未同步升高，和你观测到的现象完全匹配。

• 磁盘调度或队列配置差异
  即使主从硬件配置一致，也可能存在磁盘调度算法（如cfq、deadline、noop）或磁盘队列长度配置的差异。如果Secondary节点使用的调度算法更倾向于等待请求队列填充，会增加io_time的累计值，但实际磁盘利用率并没有同步上升。

• 采集粒度与观测窗口差异
  Telegraf的指标采集间隔通常为10-30秒，是时间段内的平均值；而iotop是实时采样（默认每秒刷新），且你仅监测了1分钟。如果Secondary节点的io_time是在采集间隔内的短时间窗口出现峰值，会拉高整体平均值，但iotop可能未捕捉到持续高占比，导致两者数据呈现差异。

• Oplog应用的额外I/O开销
  Secondary节点应用oplog时，除了数据写入，还会触发索引更新、一致性校验等额外操作。这些操作的I/O请求更细碎，会增加队列等待时间，但单进程的IO%被分散到多个小请求中，表现为iotop的低占比，但io_time累计值偏高。

内容的提问来源于stack exchange，提问作者Fume