为什么服务器上的磁盘 I/O 会飙升到 100%
磁盘 I/O 飙升到 100% 意味着你的存储子系统已经无法及时处理不断涌入的读写请求。触发原因几乎总是某个后台任务、计划任务服务，或突发的工作负载。硬件故障很少是主要原因。
高应用负载、低效查询、过于详细的日志记录、备份任务以及配置限制，通常才是最常见的罪魁祸首。你会看到延迟上升、查询卡顿、超时，以及连锁式服务故障。这些问题都会迅速损害系统性能。
本文将解释为什么磁盘 I/O 会升高、如何追踪峰值来源，以及哪些修复措施可以恢复正常吞吐量。
磁盘 I/O 基础与 100% 峰值
磁盘 I/O 指的是服务器发送到存储设备的每一次读写操作。每个请求都会带来代价。IOPS 衡量设备每秒能完成多少次此类请求。延迟衡量单次请求完成所需的时间。队列深度表示正在排队等待处理的请求数量。这三个指标是联动变化的，而且它们比单看利用率更能说明问题。
操作系统如何衡量磁盘利用率
操作系统会按固定时间间隔对存储设备进行采样。它会记录在采样窗口内，设备有至少一个请求正在处理中所占用的时间百分比。这个百分比就是你在监控工具中看到的利用率数值。100% 的读数仅仅意味着磁盘在整个采样窗口内从未空闲，并不表示磁盘已经损坏或即将损坏。
这个区别非常重要。一个繁忙的磁盘在队列较短时，依然可能快速响应请求。可如果磁盘达到 100%，同时队列又很深，那就是另一回事了。在 Windows Server 上，磁盘性能可能飙升到 90%–100%。用户会立刻感受到这种延迟。
为什么磁盘 I/O 飙升到 100% 会伤害性能
当存储被打满时，请求就会开始堆积。应用程序等待数据的时间会变长，而增加的延迟会向磁盘之上的每一层扩散。查询会停滞，超时会触发，依赖它的服务也会随之变慢。因此，磁盘 I/O 飙升到 100% 会演变成整个系统层面的问题，而不仅仅是存储问题。
CPU 的表现也能说明同样的问题。请关注 I/O wait 百分比，它显示的是处理器有多少时间处于空闲状态，只是在等待存储完成操作。
如果 I/O wait 百分比大于 1 除以 CPU 核心数，那么你的 CPU 核心就在等待磁盘。
在一台四核服务器上，这个阈值是 25%。一旦超过，处理器就无事可做，只能等存储追上来。理解磁盘 I/O 及其对系统性能的影响，要从这里开始：利用率告诉你磁盘很忙，而延迟和队列深度则告诉你这种繁忙是否真的在伤害性能。
高磁盘 I/O 负载的原因
磁盘 I/O 突然飙升到 100%，几乎总是由某个后台任务或计划服务引起。硬件故障很少是原因。你应当首先查看工作负载模式和软件行为，因为大多数故障都可以从这两个方面解释。
工作负载与应用程序原因
数据密集型应用程序如果在没有缓存的情况下执行大文件或数据库操作，就会造成很高的磁盘 I/O。每个请求都会直接打到存储设备上，队列很快就会增长。你可以通过两个信号识别这种模式：I/O 需求很高，而 CPU 利用率却很低。服务器大部分时间都耗在等待外部操作上，因此当磁盘吃紧时，处理器反而处于空闲状态。
常见例子包括：处理大量网络请求的 Web 服务器和数据库服务器、频繁读写磁盘的文件服务器，以及需要频繁发起网络请求和检索数据的客户端应用程序，例如邮件客户端或社交媒体应用。
SQL Server 实例则会以另一种形式表现出同样的问题。这里的高 I/O 通常来自大量扫描、更多的页面查找以及高页面读取量。优化不佳的查询会迫使数据库引擎读取远超结果集实际所需的数据页。一个缺失的索引，会让本该是小范围查找的操作变成全表扫描，而代价最终由磁盘承担。
软件、驱动与配置原因
并不是所有峰值都能追溯到应用需求。若某次高 I/O 持续时间固定，且 I/O 模式重复出现，那更可能是驱动或软件问题，而不是硬件损坏。规律性本身就是线索。真正的硬件退化通常表现为不稳定、无规律，而不是像节拍器一样精准重复。
例如，一个 Linux VM 如果显示磁盘读取量在 1G 左右的高位运行，这种读取流量就足以迫使其他操作等待，即便 CPU 仍有空闲容量。瓶颈出现在存储路径上，所有竞争该路径的进程都会受到影响。
多种软件和配置问题都可能产生这种压力。下表将每一种原因与可用于确认它的测试方式对应起来。
| 软件 / 驱动 / 配置问题 | 表明是软件或驱动问题（而非硬件）的证据 |
|---|---|
| OneDrive/SharePoint 文件同步打满磁盘 I/O | 临时暂停 OneDrive 同步，并观察磁盘 I/O 压力是否下降；如果性能恢复，原因就是软件（同步行为），而不是硬件。 |
| 防病毒 / EDR 扫描占用磁盘资源 | 临时暂停 AV 扫描，并检查 Task Manager 中的磁盘 I/O；如果 I/O 降低，则问题出在安全软件，而非硬件故障。 |
| 浏览器与后台进程争抢磁盘资源 | 使用 Task Manager（Ctrl+Shift+Esc）或 macOS Activity Monitor，识别哪个进程（如 Teams.exe、OneDrive、AV、浏览器）是主要的磁盘 I/O 消耗者。 |
| 桌面客户端设置、缓存或本地环境问题 | 将桌面客户端与 Web 客户端进行对比。如果 Web 客户端表现更好，则问题与桌面客户端设置、缓存或本地环境有关，而不是硬件。 |
| 过时或故障的 GPU 驱动 / 硬件加速 | 在 Teams Settings → General → Use hardware acceleration 中切换硬件加速，再测试后更新 GPU 驱动。驱动问题可能导致看似像硬件故障的渲染问题。 |
| 损坏的 Teams 缓存 | 清理 %appdata% 下的 Teams 缓存；如果问题解决，则说明这是软件/缓存问题，而不是硬件。 |
| 对 Teams 进程过于激进的 AV/EDR 扫描 | 与安全团队合作，为 Teams 进程创建安全例外，或调整扫描计划；问题得到解决即可证明属于软件原因。 |
还有一个因素值得注意。dpc 队列的组织方式会影响系统处理延迟过程调用的方式，而在高磁盘 I/O 负载下，错误配置的队列可能进一步增加延迟。无论这些来源中的哪一种造成了过量磁盘 I/O，都会拖累所有依赖存储的服务性能。在调查高磁盘 I/O 时，峰值出现的模式和时间点，是你最有力的证据。
硬件与基础设施限制
工作负载和软件问题解释了大多数峰值，但存储设备本身仍可能构成硬上限。在归咎于应用程序之前，你应该先排除这些限制。
何时是磁盘本身成为瓶颈
每块磁盘都有自己的 IOPS 上限，而一旦工作负载超过这个上限，请求就会持续排队。老旧的 HDD 所能提供的 IOPS 远低于现代 SSD，因此以前运行良好的任务，如今也可能把机械盘打满。故障中的 SSD 则表现不同：它可能在彻底损坏前就开始变慢、重试操作，或吞吐量下降。RAID 重建会给整个阵列带来大量后台读写，而这些重建流量会一直与生产业务竞争，直到重建完成。
这些情况确实存在，但比起工作负载和软件原因，它们并不常见。先检查磁盘健康状态、SMART 数据以及阵列状态。如果硬件报告正常，就应去别处查找原因。
虚拟化与云存储的影响
虚拟机会与其他租户共享物理存储。当邻居实例运行重负载任务时，你的实例也会在同一个队列里等待，于是你会看到 I/O 性能下降，但这与自身工作负载无关。云实例也面临同样的问题。云服务商会根据卷类型限制 IOPS，而共享存储池还会吸收来自其他客户的压力。
这种“噪声邻居”效应很难仅从单个来宾系统内部证明。请将你的指标与服务商基线进行比较，并在一天中的不同时间进行测试。如果某种模式总是跟着别人的作息出现，那指向的就是共享基础设施，而不是你的服务器。
与工作负载和软件原因相比，硬件故障依然很少见。应将磁盘 I/O 限制视为容量问题，而不是默认解释。当你调查瓶颈时，请先通过厂商规格和服务商文档确认上限，再决定是否更换硬件。
如何诊断高磁盘 I/O 峰值
看不见，就修不好。先用对工具，再把这些指标放在一起来看。单独一个利用率数字会误导你。延迟、队列深度和等待时间一起，才能揭示真正的问题。
首轮响应指标与命令
Linux 提供了多种适合此类工作的工具。使用 iostat 查看每个设备的吞吐量和延迟，使用 iotop 查看每个进程的活动，使用 atop 获取系统实时快照，使用 pidstat 查看按时间采样的进程级统计信息。在 Windows 上，可以使用 Performance Monitor、Resource Monitor 以及底层 Perfmon 计数器。每个工具回答的问题略有不同，所以你应根据需要确认的内容来选择。
| 工具 | 平台 | 可查看内容 |
|---|---|---|
iostat | Linux | 每个设备的吞吐量、延迟与队列深度 |
iotop | Linux | 每个进程的读写活动 |
atop | Linux | 系统范围的实时资源快照 |
pidstat | Linux | 按时间采样的进程级统计信息 |
| Performance Monitor | Windows | 历史计数器与告警 |
| Resource Monitor | Windows | 实时的每进程磁盘活动 |
请把这些指标结合起来看，不要孤立解读。高利用率但队列短、延迟低，通常是无害的。高利用率同时队列很深、延迟上升，则是紧急情况。还要检查 I/O wait。如果 I/O wait 超过 1 除以 CPU 核心数，那么处理器就是在空等存储追上来。在四核机器上，这个阈值是 25%。这种排障方法能帮助你区分：磁盘只是繁忙，还是已经成为真正的瓶颈。
将峰值追踪到具体进程
一旦确认了峰值，就要把它映射到具体来源。请按以下步骤操作：
- 在
iotop或 Resource Monitor 中按磁盘活动对进程排序。 - 记录磁盘占用最高的进程及其读写速率。
- 检查这种模式是否按固定周期重复出现，例如每 13 秒一次的模式通常说明是驱动或软件问题。
- 将其出现时间与计划任务、cron 作业和备份窗口进行交叉比对。
- 检查该进程的所有者、服务名以及启动时间。
如果一个进程只在备份窗口中出现，那就指向计划任务。如果它持续运行，那就更像应用程序或服务。如果某种模式以机械般精准的节奏重复，那通常指向驱动问题。假设你发现某个 Linux VM 的读取量达到大约 1G，而其他操作都在等待，这样的流量规模就能很快锁定元凶，你也就能及时处理。
目标其实很简单：确认峰值、找出进程、归类原因。这个顺序可以把模糊的性能下降，转化为一个具体且可修复的问题。
修复并预防 I/O 性能问题
立即缓解措施
你已经把峰值追踪到某个进程。现在就可以采取行动。先从成本最低的修复入手：限制或重新安排有问题的任务。一个在高峰时段运行的备份任务，可以挪到维护窗口。同步客户端可以在办公时间暂停。这些调整几乎没有成本，而且通常几分钟内就能缓解瓶颈。
接下来，在最需要的地方增加缓存。调整 I/O 使用最高的服务，让更多数据缓存在 RAM 中。这样可以减少对存储的直接读取并缩短队列。对于数据库工作负载，要优化慢查询并补充缺失索引。一次全表扫描会比一次单行查找带来多得多的读取压力。还应把详细日志迁移到独立卷上。若日志与数据放在同一块磁盘上，等于把同一设备上的压力翻倍。
长期预防与监控
被动修复只能争取时间。预防才能阻止问题再次发生。请在系统正常运行时为 I/O 性能建立基线。记录每个卷的典型 IOPS、延迟和队列深度。这些数字会在问题出现时成为你的参考标准。
针对延迟和队列深度设置告警，而不仅仅盯着利用率。一个 100% 但延迟很低的磁盘，说明它很忙，但依然健康。一个仅有 60% 利用率却延迟持续上升的磁盘，反而是危险信号。在高磁盘 I/O 负载再次来临之前，提前做好容量规划。每个季度审查增长趋势，并在需求到来前预先扩容存储。当你能及早发现问题时，管理和解决这类故障就会容易得多。高磁盘 I/O 负载下的性能表现，依赖的是准备，而不是运气。
磁盘 I/O 飙升到 100% 是一种症状，而不是根本原因。真正的答案通常隐藏在工作负载模式、应用程序行为或基础设施限制之中。请遵循这个顺序：确认峰值、识别进程、归类原因、然后采取措施。这个流程能把模糊的系统变慢，转变成一个可定位、可修复的问题。
主动监控可以预防大多数事故。跟踪基线、延迟和队列深度——而不仅仅是利用率。一个繁忙但队列短的磁盘依然健康。延迟上升则是提早暴露风险的信号。
应把磁盘 I/O 视为容量和架构设计问题。要在高负载再次出现之前就规划好存储增长。你的系统性能依赖准备，而不是运气。
常见问题
磁盘显示 100% 就意味着硬盘要坏了吗？
不是。这个数值只表示设备在采样窗口内始终处于忙碌状态。故障中的磁盘通常表现为无规律的异常，而不是稳定的高饱和。请先检查 SMART 数据和阵列状态以排除硬件问题。如果这些都正常，就应把重点放在工作负载和软件上。
我怎样判断原因是软件还是硬件？
观察时序模式。重复出现的规律通常指向驱动或软件问题；硬件退化则更像是随机发生。你也可以暂停一个可疑服务，例如同步客户端或防病毒扫描，看看压力是否下降。若暂停后恢复正常，就能确认是软件原因。
当利用率看起来很高时，哪个指标最重要？
延迟和队列深度比单纯的利用率更有参考价值。一个繁忙但队列短的磁盘依然健康。延迟上升才是真正的危险信号。同时也要检查 I/O wait。当它超过 1 除以 CPU 核心数时，处理器就是在空等存储响应。
虚拟机会自己造成存储瓶颈吗？
有时会。但你的实例也在与其他租户共享物理存储。邻居实例运行重负载任务时，会把你的请求一并推入同一个队列。请将自己的指标与服务商基线比较，并在不同时间段测试。如果某种模式总是跟着他人的时间表出现，那就说明问题出在共享基础设施。
当峰值出现时，我应该先修什么？
先限制或重新安排有问题的任务。把备份任务挪到维护窗口，或在办公时间暂停同步客户端。然后再增加缓存、优化慢查询，并把详细日志迁移到单独的卷上。这些措施通常能在几分钟内缓解瓶颈。
