不一定。load average 高但 cpu 使用率低，说明进程可能卡在 i/o、锁或不可中断睡眠（d 状态），而非 cpu 瓶颈；需结合 r 值、d 进程、wchan 和 cswch/s 等指标定位真实瓶颈。
load average 高但 CPU 使用率低，是真过载吗？
不一定。load average（平均负载）反映的是“等待 CPU 或不可中断状态的进程数”，不是 CPU 占用率本身。比如大量进程卡在磁盘 I/O、锁竞争、或 uninterruptible sleep（D 状态），top 里 %us 和 %sy 可能很低，但 load average 却飙升——这时压根不是 CPU 不够，而是其他资源堵住了。
- 用
ps aux | awk '$8 ~ /D/ {print}'快速筛出 D 状态进程，重点查是否卡在 NFS、挂载异常、或内核模块死锁 -
vmstat 1看r（运行队列长度）是否持续 > CPU 核心数；若r高但us/sy低，大概率是 I/O 或锁阻塞 - 注意：单核机器
load average> 1.0 才算过载；8 核机器load average= 5.0 是正常范围，别一看到数字大就 panic
怎么快速定位谁在拉高 load average？
别只盯着 top 的 %CPU 排序——它漏掉了 D 状态和刚 fork 出来还没调度的进程。真正有效的组合是：pidstat -w 1 + ps -eo pid,ppid,state,comm,wchan --sort=-wchan。
-
pidstat -w 1的cswch/s（每秒上下文切换）若 > 10000，说明有大量短命进程（如 PHP-FPM 子进程爆炸、日志轮转脚本频繁启停） -
wchan列显示进程当前等待的内核函数，比如wait_event_interruptible（等信号）、__common_interrupt（硬中断）、ext4_file_write_iter（写文件卡住）——这比看状态字母更准 - 如果
ps输出里一堆同名进程（如rsyslogd）反复出现又消失，检查其配置是否触发了高频重载（kill -HUP频繁）
/proc/loadavg 的三个数值到底怎么看？
它们分别是 1 分钟、5 分钟、15 分钟的指数衰减平均值，不是简单滑动窗口。关键不是“哪个高”，而是看趋势是否收敛——比如 1.2, 3.5, 6.8 说明负载在快速恶化；8.1, 7.9, 7.7 说明已稳定在高位，该查长周期瓶颈了。
- 用
uptime比cat /proc/loadavg更直观，且自动带出核心数：load average: 4.20, 3.85, 3.21 (8 CPU) - 不要单独看 1 分钟值——它波动大，可能只是某次批量任务启动；重点对比 5/15 分钟值是否同步走高
- 容器环境要注意：cgroup v2 下
/proc/loadavg是宿主机全局值，不代表当前容器实际压力；得看/sys/fs/cgroup/cpu.stat的nr_runnable
哪些“优化”反而会让 load average 更难读？
调 vm.swappiness、换 I/O 调度器、甚至关掉 irqbalance，都可能让 load average 数值失真——不是问题变少了，而是阻塞路径变了，系统把等待“藏”到了别处。
- 把
swappiness=0后，内存不足时不再 swap，但 OOM Killer 触发更快，进程直接被杀，load average可能骤降，可业务已断了 - SSD 上强行切回
deadline调度器，%util看着降了，但await可能翻倍，因为请求没被合并，更多进程在排队等响应 - 禁用
irqbalance并手动绑中断到单核，top里那颗 CPU 爆到 100%，但其他核空闲，load average却可能比均衡时还高——因为中断处理线程全挤在一条跑道上
load average 是个“症状指标”，不是病因。盯着它调参数，就像根据体温吃退烧药却不查感染源。真正要盯的是 r、D 进程数、cswch/s、wchan 这些底层信号——它们才告诉你，系统到底卡在哪条流水线上。