网站打开缓慢、SSH操作卡顿，监控中的系统负载不断升高，但CPU使用率只有20%或30%，这是服务器配置不够吗？
这种情况需要先判断任务在等待什么。磁盘I/O、内存换页、虚拟机调度等待，以及已经结束的短时高峰，都可能造成负载与当前CPU使用率看起来不一致。
本文适用于Linux VPS和独立服务器，命令在服务器SSH终端执行。使用root登录时，可以省略命令中的sudo。
一、先理解：系统负载和CPU使用率有什么区别？
执行：
uptime
nprocuptime显示运行时间和负载，例如：
load average: 8.20, 6.40, 3.10三个数值分别对应最近1分钟、5分钟和15分钟的平均负载。
Linux的负载统计包含可运行任务，以及不可中断等待状态的任务。前者包括正在使用CPU和等待CPU的任务，后者常见于I/O等待。因此，负载高不一定意味着CPU正在大量计算。
nproc显示当前进程可使用的逻辑CPU数量，可作为判断CPU排队情况的参考。
例如，一台4核服务器的负载为8，并不能直接解释成“CPU使用率200%”。需要继续查看，这些任务是在排队计算，还是卡在其他资源上。
另外，负载是经过平滑处理的趋势指标。短时高峰结束后，即使CPU已经恢复空闲，负载也不会立即降下来。
二、使用vmstat判断主要等待方向
执行：
vmstat 1 6命令每秒输出一次，共输出6次。第一行中的CPU、I/O等速率统计主要是开机以来的平均值，排查当前问题时重点看后续几行；进程和内存字段则是即时数据。
重点观察以下字段：
| 字段 | 含义 | 排查方向 |
|---|---|---|
r | 正在运行或等待CPU的任务数 | 持续偏高时检查CPU排队 |
b | 等待I/O完成的阻塞任务数 | 持续出现时检查存储与阻塞任务 |
us、sy | 用户态、内核态CPU时间比例 | 判断CPU实际忙在哪一侧 |
wa | I/O等待相关CPU时间比例 | 配合磁盘指标判断 |
si、so | 每秒换入、换出的内存量 | 持续活跃时检查内存压力 |
st | 虚拟机被占用的CPU时间比例 | 检查虚拟化层面的调度等待 |
这些字段需要一起看，不能只根据某一列得出结论。
例如，CPU计算占用不高，但b持续较多，可以优先检查I/O；如果si、so同时持续活跃，还需要判断是不是内存不足引起了频繁换页。
对于间歇性卡顿，几秒采样可能碰不到问题，应在故障发生时延长观察时间。
三、检查磁盘I/O是否出现排队
后面的iostat、pidstat和mpstat属于sysstat工具集。尚未安装时，按系统选择对应命令。
Debian、Ubuntu：
sudo apt update
sudo apt install -y sysstatRocky Linux、AlmaLinux：
sudo dnf install -y sysstat安装后执行：
iostat -xz -y 1 5这条命令显示扩展I/O指标，跳过开机以来的首次统计，每秒采样一次，共输出5次，并隐藏当前没有活动的设备。
重点关注：
r_await： 读请求平均完成时间，单位为毫秒，包含排队时间。w_await： 写请求平均完成时间，同样包含排队时间。aqu-sz： 平均I/O队列长度。%util： 设备忙碌时间比例。
对于NVMe、现代SSD和RAID，不能仅凭%util接近100%就判断磁盘已经达到性能上限。 这些设备能够并行处理请求，还需要结合请求延迟、队列变化和业务响应情况分析。
如果卡顿时读写延迟明显高于平时，队列也持续增加，就有理由优先检查存储路径及正在运行的读写任务。
支持PSI的系统，还可以查看I/O压力：
cat /proc/pressure/io其中，some表示至少部分任务因I/O而停顿的时间比例，full表示所有非空闲任务同时因I/O停顿的时间比例。avg10、avg60、avg300分别反映最近10秒、60秒和300秒的趋势。
这些数值反映的是任务受到的影响，不是磁盘带宽使用率。
四、找出哪些任务被阻塞、哪些进程在读写
1. 查看D状态任务
执行：
sudo ps -eLo pid,tid,stat,wchan:32,comm | awk 'NR == 1 || $3 ~ /^D/'输出字段包括：
PID：进程ID。TID：线程ID。STAT：任务状态。WCHAN：任务等待的内核位置。COMMAND：任务名称。
这里按线程查看，能够发现同一个进程中被阻塞的线程。D表示不可中断睡眠，通常与I/O有关，但看到D状态并不能直接证明物理硬盘损坏。
如果只显示表头，表示采样时没有匹配到D状态任务；瞬时阻塞仍可能被漏掉，需要在卡顿时重复观察。
2. 查看进程读写活动
执行：
sudo pidstat -d 1 5重点关注kB_rd/s和kB_wr/s，分别表示进程引起的磁盘读取和写入速率。将活跃进程与备份、数据库、日志处理等任务对应起来，检查它们是否恰好在卡顿期间运行。
需要区分“制造大量I/O的进程”和“被I/O拖慢的进程”。一个任务处于D状态，可能只是受到其他任务影响，不能直接把它认定为根因。
3. 查看同一时段的内核日志
使用systemd的系统可以执行：
sudo journalctl -k -b 0 --since "30 minutes ago" --no-pager这会查看本次启动后、最近30分钟的内核日志。重点留意存储错误、设备超时、重置，以及网络文件系统无响应等信息，并与卡顿时间对应。
如果业务使用NFS等网络存储，也需要检查远端服务和连接状态，本地磁盘指标无法覆盖整条访问路径。
五、磁盘没有明显异常，再看每个CPU和虚拟机调度
执行：
mpstat -P ALL 1 5这个命令分别显示各个逻辑CPU的使用情况。整体CPU平均值不高时，仍可能有部分CPU已经忙满，应进一步检查应用线程分布及CPU绑定情况。
对于VPS，还需要观察%steal，它对应前面vmstat中的st，反映虚拟CPU在虚拟化层面被迫等待的时间。
如果该指标在业务卡顿期间持续偏高，可以记录时间、采样结果和业务表现，提交给服务商检查宿主机调度情况。仅凭一次采样，不能确定具体原因。
如果应用运行在容器中，还应核对容器的CPU配额。宿主机存在空闲CPU，并不代表受配额限制的应用能够继续使用这些资源。
六、根据证据处理，再验证业务是否恢复
下面这些现象可以帮助确定处理方向，但都需要结合相同时间段的数据判断：
| 观察到的现象 | 优先处理方向 |
|---|---|
| 备份期间I/O延迟和队列明显上升 | 调整备份时段，降低备份并发或传输速率 |
| 数据库读写增加，业务请求同时变慢 | 检查慢查询、索引和批量任务 |
| 持续换页并伴随卡顿 | 检查内存占用，减少并发或调整内存配置 |
| 部分CPU持续忙满 | 检查应用线程、CPU绑定及任务分配 |
%steal持续偏高并伴随业务延迟 | 保留采样结果，联系服务商排查 |
| 日志出现设备超时或存储错误 | 排查对应设备、驱动或存储后端 |
调整时尽量一次只改变一个因素，并记录调整前后的差异。例如，将备份任务错峰后，观察I/O延迟、阻塞任务数量和网站响应是否同时改善。
验证效果时，优先看业务响应和当前采样指标。5分钟、15分钟负载会缓慢回落，不必要求它们在处理完成后立即归零。
