应优先看 load average 判断系统负载是否越界，而非仅盯 cpu%；再结合 %us、%sy、%wa 区分根因，辅以 vmstat、iostat、pidstat 等工具定位真实瓶颈。
平均负载（load average）是 Linux 系统性能诊断的起点，但它本身不直接告诉你“哪里卡”，而是提示“有没有卡”以及“可能卡在哪”。关键在于结合 CPU 核心数看数值、对照三时段趋势看变化、再搭配 %us/%sy/%wa 和进程状态定位根因。
看 load average 是否越界，先算清 CPU 核心数
load average 的三个值（1/5/15 分钟）代表单位时间内处于 R（运行）或 D（不可中断睡眠）状态的平均进程数。它不是 CPU 使用率，而是“活跃任务数”的宏观反映：
- 单核系统：load > 1.0 就说明有进程在排队等待
- 4 核系统：load > 4.0 才算真正承压；若 load 是 3.2，实际 CPU 利用率约 80%
- 虚拟机或容器中要注意：lscpu 或 nproc 查出的“逻辑 CPU 数”才是对标基准，不是物理核数
盯三值趋势，区分突发 vs 持续压力
1 分钟值远高于 15 分钟值（如 8.2, 3.1, 2.7），说明刚有短时高峰，可能是 cron 任务、日志轮转或一次批量查询，未必需扩容；而三值持续高位（如 6.5, 6.3, 6.4）才表明瓶颈已固化。
如果 15 分钟值不断爬升，即使当前 load 看似可控，也意味着资源正在被缓慢耗尽——比如内存泄漏导致 swap 活跃、或磁盘队列持续堆积。
结合 %us / %sy / %wa，快速划出瓶颈类型
top 或 mpstat 输出的 CPU 使用分解，是判断 load 高根源的关键线索：
- %us 高（>70%）：用户态代码占满 CPU，常见于 Python 循环、Java GC 频繁、未优化的正则匹配等，应查 top 中排序靠前的进程及其线程（ps -T -p PID）
- %sy 高（>20%）：内核开销异常，可能源于高频系统调用（strace -c -p PID）、网卡软中断不均（cat /proc/interrupts | grep eth）、或 cgroups 限流引发调度抖动
- %wa 高（>15%）：CPU 在等 I/O，此时必须跑 iostat -dx 1 —— 若 %util ≥ 95% 且 await 显著超标（HDD >10ms，SSD >1ms），是本地磁盘瓶颈；若 %util 很低但 %wa 高，问题大概率出在存储后端（NFS 响应慢、Ceph OSD 故障、SAN 路径中断）
验证 D 状态进程和换页行为，排除假性高 load
大量 D 状态进程（ps aux | awk '$8 ~ /D/ {print}'）会让 load 飙升，但 CPU 可能很闲。常见于：
- NFS 挂载点无响应，进程卡在 vfs_read
- USB 设备异常或 SCSI 设备超时
- 内核模块死锁或驱动 bug
同时执行 vmstat 1 5，观察 si/so 列：只要连续非零，说明已在 swap，物理内存不足；dmesg -T | grep "killed process" 有输出，则 OOM Killer 已介入，属于内存硬瓶颈，和 load 数值高低无关。
