服务器负载升高时，如何区分 CPU 饱和与 I/O 等待

📈 服务器负载升高：区分 CPU 忙与 I/O 等待

Linux 的 Load Average 统计可运行任务以及部分不可中断等待任务的平均数量，不是 CPU 利用率。大量进程等待存储时，负载可以升高而 CPU 仍有空闲；反过来，单个 CPU 核心饱和也可能被多核总平均稀释。判断瓶颈要同时看任务队列、每核状态、设备延迟和应用响应。

🔎 一、建立同一时间窗口的 CPU 视图

先用 uptime 查看 1、5、15 分钟负载，并与逻辑 CPU 数量和该主机正常时段的基线比较。再用 mpstat -P ALL 1 连续观察各 CPU 核的用户态、系统态、空闲和 I/O 等待比例。若少数核持续接近满载而其他核空闲，可能是单线程热点、线程绑核或负载分配不均；不能只看全机平均值。

%usr 持续高常指向应用计算、紧循环或请求量上升；%sys 持续高则提示内核路径、系统调用、网络处理或上下文切换成本增加。%iowait 是 CPU 处于空闲且存在未完成 I/O 的时间比例，其口径受内核和环境影响，不能独立证明磁盘就是根因。

🧭 二、确认设备等待是否与负载同步

用 iostat -xz 1 观察吞吐、队列、等待时间和设备利用趋势。重点寻找与负载升高同时出现的延迟抬升、队列持续增加，以及业务读写模式变化。虚拟化或云块存储环境下，指标的呈现和聚合方式可能不同，应优先比较同一实例、同一设备和同一采样周期的历史数据。

若 CPU 空闲仍高，进程大量处于不可中断等待，且设备等待指标同步恶化，I/O 瓶颈的可能性上升。若设备指标稳定而某些 CPU 核持续饱和，应转向计算热点。还要检查内存压力导致的换页，因为它会让磁盘活动增加，表现得像普通业务 I/O。

📊 三、把主机指标关联到具体进程和事件

使用 pidstat -u -d 1 对照进程 CPU 与读写量，查看热点是否集中在少数进程。再把采样时间与请求速率、后台批处理、备份、定时任务、部署或配置变更对齐。若多个进程同时等待同一设备，调查共享数据卷和文件系统；若单个进程异常，应检查其线程、请求队列和重试行为。

✅ 四、常见误判与验收

把 Load Average 当成 CPU 百分比、仅凭高 %iowait 定性磁盘故障，或只看总 CPU 平均，都可能选错处理方向。处理后应在相似业务负载窗口重复采样，确认负载和队列不再持续增长、设备延迟回到主机基线范围，并检查应用响应时间和成功率。保留前后指标与事件时间，才能证明根因已缓解而非负载暂时消退。