### [VPS负载很高但CPU并不忙？用运行队列、I/O等待和D状态定位](https://www.jiyueip.com/article/13482)

**Published:** 2026-07-30T07:37:47

**Author:** 斑斓助理

**Excerpt:** Linux VPS的Load Average不仅统计正在用CPU的任务，也包含不可中断等待。本文用uptime、vmstat、ps、iostat和PSI区分CPU排队、磁盘等待、cgroup限额与宿主机争用。

VPS的Load Average很高，而监控里的CPU使用率并不高，通常不是指标“坏了”。Linux负载会统计正在运行、等待CPU以及处于不可中断等待的任务；大量进程卡在磁盘、网络存储或内核I/O时，即使CPU仍有空闲，负载也会持续上升。

## 先别急着重启：把同一时间点的证据留住

故障发生时先记录时间、业务症状和下面几组只读输出。重启可能暂时清空队列，却也会让D状态进程、内核日志和压力变化消失，后续很难判断是应用并发、存储延迟还是宿主机问题。

```
uptime
top
vmstat 1 5
ps -eo state,pid,ppid,comm,wchan:32 | awk '$1 ~ /^D/'
cat /proc/pressure/cpu
cat /proc/pressure/io
```

`uptime`给出1、5、15分钟负载；`top`要同时看CPU的`us`、`sy`、`id`、`wa`和虚拟机常见的`st`；`vmstat`里的`r`表示可运行队列，`b`表示等待I/O的任务。单个瞬时值很容易误判，应对照多个采样点和机器平时基线。

## Load Average高，可能是哪一种队列

| 现象组合 | 更可能的方向 | 下一步 |
| --- | --- | --- |
| 负载高，CPU的us/sy也高，r持续偏大 | 可运行任务争抢CPU | 定位高CPU进程、线程数与cgroup配额 |
| 负载高，CPU空闲仍多，b和D状态任务增加 | 块设备或网络文件系统等待 | 检查iostat、内核日志、挂载与存储服务 |
| 负载高，wa明显，磁盘延迟同步升高 | I/O队列拥塞 | 区分读写突发、日志、数据库和备份任务 |
| CPU使用不高，但st持续出现 | 虚拟化宿主机争用 | 保留时段证据并与VPS服务方核对 |
| 容器内任务排队，整机CPU仍有余量 | cgroup CPU限额或节流 | 检查cpu.stat与容器资源限制 |

表格是定位方向，不是固定阈值。核心数、内核版本、存储类型和业务模型不同，“负载多少算高”没有统一答案；更可靠的判断是队列是否持续增长，以及它是否与响应变慢、超时或吞吐下降同时出现。

## CPU队列和cgroup限额怎么分开看

如果`vmstat`的`r`持续较大，先用`top`或`pidstat -u 1 5`找出占用CPU的进程。若宿主机整体CPU仍空闲，但容器或服务响应变慢，应检查它是否受CPU配额限制：

```
cat /sys/fs/cgroup/cpu.stat
systemd-cgtop
```

在使用统一cgroup层级的系统中，`cpu.stat`里的节流计数持续增加，说明任务有运行需求却被配额限制。此时简单增加应用线程可能让队列更长；应先确认容器或systemd单元的资源配置，再决定调额还是降低并发。

## D状态任务为什么杀不掉

D状态表示任务正在不可中断等待，常见于块设备请求、故障磁盘、NFS/CIFS挂载或内核驱动路径。`kill -9`只能把信号挂起，通常不能让正在内核等待中的任务立即退出。应查看`wchan`、内核日志和对应挂载，而不是反复发送信号。

```
dmesg -T | tail -n 100
mount | grep -E 'nfs|cifs'
lsblk
```

如果日志出现I/O error、reset、timeout或文件系统报错，应先保护数据和停止新增写入，再按存储类型处理。不要在未备份、未确认文件系统状态时强制修复或强制重新挂载。

## 磁盘忙不忙，不能只看使用率

安装了`sysstat`后，可用下面的短时采样观察设备队列和延迟：

```
iostat -xz 1 5
pidstat -d 1 5
```

重点对比读写吞吐、平均等待、队列长度和具体进程。某块盘的`%util`很高不必然等于故障，现代存储可以并行处理请求；反过来，吞吐量不大但等待时间突然上升，也可能已经影响交互业务。应与同一实例的平时数据比较，而不是套用一个通用毫秒阈值。

若高负载与日志压缩、备份、数据库检查点或镜像拉取同时发生，可先平滑降低这些任务的并发或错开时间窗口。若所有进程都受影响且内核日志出现设备异常，再把问题升级到文件系统、云盘或宿主机层面。

## 网络文件系统和宿主机争用也会抬高负载

NFS或CIFS服务端延迟时，本地进程可能大量进入D状态，CPU却保持空闲。检查挂载目标的连通性、服务端状态和超时日志，并确认业务是否把关键路径放在网络盘上。

在VPS中，`top`的`st`代表虚拟CPU等待宿主机调度的时间。若它在故障窗口持续出现，同时同机业务变慢，应保存监控截图、采样时间和实例信息给服务方。一次瞬时`st`不能证明宿主机长期超售。

## 按风险从低到高处理

1.  保留`uptime`、`vmstat`、D状态进程、PSI和内核日志。
2.  停止或降低可确认的非关键批任务并发，观察队列是否回落。
3.  对照具体进程检查磁盘、网络挂载、数据库和容器资源限制。
4.  出现设备或文件系统错误时先保护数据，再进入维护窗口处理。
5.  证据指向云盘延迟或CPU steal时，携带同一时间窗数据联系服务方。

恢复后至少对照一个相同业务时段，确认负载、响应时间、I/O压力和错误日志同时回到基线。只看到Load Average下降，并不能证明根因已经消失。

## 结论

VPS负载高但CPU不忙，优先寻找“谁在排队”：`r`指向CPU运行队列，`b`和D状态指向不可中断等待，`wa`和I/O PSI帮助确认存储压力，`st`提示虚拟化争用，cgroup节流则解释局部服务为何排队。按这条证据链处理，比直接重启或盲目升级CPU更容易找到真正瓶颈。

**Tags:** Linux服务器, VPS, VPS性能, VPS监控, 网络故障排查

**Categories:** 行业洞察

---