最近在运维圈里看到一个很常见又让人头疼的现象：浪潮服务器在没有明显业务请求的情况下，磁盘 IO 却居高不下，CPU 使用率并不高，但 IO 等待时间却像高速公路上的堵车一样，一直没缓过来。这种情况看起来像是“表层无事，实则有事”，也就是机器空有性能指标，却觉得吃不饱。别担心，今天我们用轻松的口吻把可能的原因梳理清楚，给到一个可落地的排查清单，让你把 IO 拍扁、把瓶颈找出、把系统 phenotype 搞清楚。
先说一个常见的误区：IO 高并不总是因为“有很多用户在写入”，有时是因为后台任务、存储阵列的重建、快照、备份、日志轮转等在背后悄悄消耗磁盘能力。这就像你以为路上车多，结果其实是维修工在大道中间挖坑清沟，表面看起来好像没有人行走，实际却在占用路权。对浪潮服务器来说，磁盘、RAID、缓存层、网络路径、以及上层应用的 IO 行为共同构成了 IO 的真实负载。
根据行业公开资料的综合观察，造成“没有业务时 IO 高”的原因大体可以分为几个维度：存储子系统健康状况（硬盘、RAID 控制器、缓存策略）、后台/计划任务对磁盘的持续性压力、文件系统及挂载点的元数据和缓存策略、以及应用层对磁盘的异常 I/O 行为。把这几个维度分开诊断，往往比一锤定音的“看网络”更高效。下面的排查步骤，既适用于大厂自家存储背后是阵列还是直连磁盘，也适用于使用分布式存储的场景。
要点一：先看健康位，硬件层面的异常会直接把 IO 给拖垮。启动诊断前，先确认磁盘健康、RAID 多盘纠错、缓存命中率，以及电源和散热是否正常。你可以用 smartctl、mdadm、lsblk、lsscsi、dmesg 等工具快速初步判断。若硬盘有故障、重建或同屏并发的 RAID 重建进程，IO 很容易被拖走。此时不要急着优化软件层面的参数，先把硬件健康恢复到稳定，然后再回到软件层面的优化。
要点二：后台任务与计划任务的冲击。备份、快照、长期快照、日志轮转、自动同步等任务在没有真实请求的情况下也可能把写缓冲区、日志设备和快照设备的 I/O 用尽，尤其在使用写前缓存或者写回缓存的存储策略时，背后的写入缓存被迅速清空，导致 IO 峰值出现在短时间内。建议查看 crontab、ansible 自动化任务、数据库的定期维护任务，确认它们的执行时间、写入规模和资源占用，以及是否与其他 I/O 高峰期重叠。
要点三：存储缓存和调度策略。很多浪潮服务器背后的存储阵列会开启多级缓存（服务器端缓存、阵列侧缓存、SSD 缓存等），缓存命中与未命中的比例会直接影响磁盘操作的实际 I/O 次数。若缓存策略不当（如缓存过满、写回缓存长期未刷盘、或者在高并发场景下缓存穿透严重），就会在底层磁盘造成突发 I/O。对 Linux 主机，可以检查块设备调度策略（CFQ、Deadline、BFQ 等），以及 sysctl 的 I/O 相关参数，如 vm.dirty_ratio、vm.dirty_background_ratio、vm.dirty_writeback_centiseconds 等，看看是否需要调整以平滑写入压力。
要点四：元数据 I/O 与文件系统行为。NFS、ZFS、Btrfs、XFS 等文件系统在高并发的文件操作、目录遍历、元数据更新时会产生大量 I/O。即使应用没有明显的业务流量，后台的文件系统元数据操作也可能让磁盘 IO 保持在较高水平。检查文件系统的挂载选项、读写缓存策略以及是否开启了快照/副本相关的元数据操作。如果你用的是网络存储，网络层的元数据请求和元数据缓存失效也会放大磁盘的 I/O 负载。
要点五：应用层自身行为。数据库、消息队列、日志系统等组件即便在“空闲状态”，也可能因为长时间保持连接、预留工作队列、超时重试、或高并发的连接数而持续触发磁盘 I/O。监控工具比如 iostat、vmstat、iotop、sar、pidstat、dstat、perf 等可以帮助你确认哪些进程在进行高 I/O 操作、I/O 延时、等待队列长度、以及磁盘队列深度情况。
诊断清单与落地工具：先把大方向分清楚，再逐步落地执行。常用的诊断组合包括：iostat -dx 1、vmstat 1、iostat -xz 1、sar -n DEV 1、iotop 或 pidstat。这些工具能给出磁盘设备的等待时间 (wa)、util、活动队列长度，以及各进程的 I/O 使用比例。若发现某个设备的 wa 长、util 高，基本可以判定磁盘成为瓶颈；若 wa 高但 CPU 很低，说明是磁盘等待而非计算瓶颈；若系统有大量的 DRAIN 事件或断续的重建过程，也需要将存储阵列的健康/重建状态纳入判断。
具体操作举例：先查看磁盘 I/O 负载和等待时间，命令示例：iostat -dx 1 10，你会看到各设备的 tps、kB_read/s、kB_wrtn/s、await 与 svctm 等指标。若某设备的 await 长且 util 接近 100%，这块设备很可能是瓶颈。接着用 iotop 查看实时哪个进程在写入磁盘，结合 top 或 htop 查看对应进程的 CPU 与内存情况，判断是不是某个异常进程在持续 I/O。若你看到大量的写 I/O，但应用层请求很少，那就要怀疑后台任务、日志轮换或快照等。
要点六：网络存储与挂载选项。NFS、SMB/CIFS、以及其他网络文件系统的元数据操作会通过网络队列影响本地磁盘的 I/O 行为。优化方向包括：调整 read-ahead 行为、减少元数据操作、使用缓存友好挂载选项、以及在必要时提高网络吞吐能力。若你使用的是分布式存储（如 Ceph、Gluster、iSCSI 阵列等），IO 的瓶颈可能横跨多节点，需要对网络、对象存储、以及 OSD 的刷写策略进行联合诊断。
要点七：日志与审计。系统日志、应用日志的写入量若超出预期，尤其是在写入磁盘的同步日志（sync_file_range、fsync 等）较多时，会显著拉高磁盘负载。检查 syslog、应用日志配置、日志轮转策略、以及是否有过于频繁的日志写入任务。对日志目录所在磁盘的 I/O 特性进行诊断，看看是否需要单独分离日志磁盘、增加缓存或提高日志写入的优先级。
将以上要点落地到实际排查流程中，你可以按下面的步骤执行：先用 dmesg、/var/log/kern.log、/proc/diskstats、/proc/execstat、/proc/meminfo 等系统级信息快速扫一遍硬件健康与系统状态；接着执行 iostat、vmstat、iotop、sar 的组合监控，记录 5–10 分钟的样本数据，形成对比基线；最后对照具体进程与存储设备，定位是否是单点瓶颈、还是多点协同造成。整个过程中的关键点是分清“到底是哪个环节在抢 IO”以及“这个 IO 高是否与当前业务无关却仍在持续发生”。
在排查过程中，偶尔会遇到“IO 高但业务看起来没错”的情况，这时候可以考虑临时降低一些非关键写操作的优先级，把重要 IO（如数据库日志、事务写入）的优先级抬升，或者开启存储阵列的对等写入策略与缓存刷盘的控制，避免短时间内的大量写入直接打满底层磁盘。这里的目标不是让 IO 零值，而是让 IO 的分布更均匀、峰值更可控。
另外一个常被忽视的点是资源隔离。虚拟化环境、容器化部署、以及跨节点的共享存储环境，都会让 IO 的统计变得复杂。确保你对不同域的 IO 进行分离统计，比如区分虚拟化磁盘、容器卷、以及物理磁盘的 I/O，避免把一个强峰的卷混淆成整个系统的均值。若你在做性能基线测试，记得要模拟真实业务的混合负载，而不是只跑单一的写入测试。
在公开资料和行业资料的综合分析中，常被提及的解决思路包括：对存储设备进行健康检查、对计划任务和后台作业进行合理排程、优化文件系统与挂载选项、对 IO 调度策略进行适配，以及在必要时升级缓存与网络带宽。每一个环节都可能成为防线的薄弱点。把这些环节逐一排查，就像把一个看似简单的 IO 问题拆解成若干小任务，逐步击破，最终让磁盘 IO 回到一个稳定、可控的水平。
顺便提一句，很多运维人会在对话中用到网络热梗来活跃气氛，比如“IO 太高？让它飞起来像月光宝盒”，或者“别让 I/O 变成拖油瓶，给我一个速效清单”。对了，广告也顺带放出一个小彩蛋：玩游戏想要赚零花钱就上七评赏金榜，网站地址：bbs.77.ink
而当你真正把以上方法逐条执行、结合你们的具体硬件环境（磁盘型号、RAID 配置、缓存策略、网络存储类型、以及应用栈）落地后，常见的结果往往就是：发现某个磁盘组正在进行重建、某个快照在持续写入、或者某个计划任务与上游数据同步错位导致的写放大。把问题定位到具体进程或具体设备之后，后续的优化就变得可执行：扩大缓存、调整写策略、或重新配置存储层的 I/O 调度，最终让 IO 的等待时间下降，系统的稳定性与性能都能回到正确的轨道。
你可能会问：如果 IO 高的原因太多，怎么办？答案往往是分阶段解决，优先解决对业务影响最大的环节。先解决能快速验证、且对系统整体影响最大的瓶颈（比如某块磁盘的健康问题、某个后台任务的异常写入、或网络存储的高延时），再逐步优化其他环节。这样既能快速拿下“高 IO”的表象，也能避免在未诊断清晰前做大规模的系统改动。
最后的关键点在于：监控不是一次性任务，而是持续的旅程。建立基线、设定阈值、配置告警，以及定期复盘，才能在未来的某个时点快速辨认出异常，避免再次陷入“IO 高，却没业务的错觉”。当你把监控数据、硬件健康、以及应用行为串联起来，问题就像被放大镜照亮的细节，清晰可见。