load average 很高但 CPU 使用率不高，可能是什么原因？先看哪个命令？

常见是进程处于 D 状态，在等磁盘、NFS 或内核锁；先看 ps -eo pid,stat,wchan,comm，再用 iostat -x 确认 IO。

容器里 top 看到的是宿主机 CPU，怎样确认容器是否被 cgroup 限流？

看 cgroup v2 的 /sys/fs/cgroup/cpu.stat，重点看 nrthrottled 和 throttledusec 是否持续增长，并结合 CPU limit 判断。

用户态高和内核态高，分别应该先查什么？

用户态高先用 perf top 或语言 profiler 找热点函数，pidstat -u 看进程；内核态高先用 mpstat、pidstat -w、sar -n DEV 看系统调用、上下文切换和网络软中断。

CPU 使用率高：先分清用户态、内核态、iowait 与限流，再进入具体命令

补充说明

CPU 高只是现象，先回答三个问题：是整机还是容器？是用户态还是内核态？是真忙还是被限流、等待？load average 包含不可中断睡眠（D 状态）进程，高 load 不等于 CPU 忙；容器里的 top 往往看到宿主机数据，必须结合 cgroup 的 cpu.stat。本页是分诊入口，单条命令的参数与原理见各命令页和 Linux 性能排查路线。

边界：不覆盖磁盘 IO、内存回收和 JVM GC 的完整调优；iowait 高时转到磁盘 IO 高，OOM 见 oom-killed。

3 分钟定位

nproc; uptime
top -b -n1 -H | head -30
pidstat -u -t 1 5
mpstat -P ALL 1 5
cat /proc/pressure/cpu
ps -eo pid,stat,pcpu,pmem,wchan:24,comm --sort=-pcpu | head

容器或 Kubernetes 里补查 cgroup 与集群视图：

cat /sys/fs/cgroup/cpu.stat
kubectl top pod -A --sort-by=cpu | head
kubectl top node

现象	优先检查	入口
load 高但 CPU 不满	D 状态、IO 等待、锁	`ps -eo stat,wchan`、磁盘 IO 高
用户态高	热循环、GC、序列化、正则	`perf top`、`pidstat -u`
内核态高	系统调用、软中断、上下文切换	`mpstat`、`pidstat -w`、`sar -n DEV`
iowait 高	磁盘、NFS、网络存储	`iostat -x 1`、磁盘 IO 高
steal 高	虚拟机邻居争抢	云监控、宿主机指标
容器 CPU 不高但变慢	cgroup 限流	`cpu.stat` 的 `nr_throttled`
单核 100%、多核空闲	单线程瓶颈	`top -H`、`perf`

根因树

用户态忙：死循环、频繁 GC、JSON/正则/压缩、锁竞争、日志过多。先 perf top 或语言级 profiler 定位热点函数，再决定优化代码还是加资源。
内核态忙：系统调用过多、网络软中断、上下文切换、容器运行时开销。看 pidstat -w 的自愿/非自愿切换，mpstat 的 %sys，以及 sar -n DEV 的包量。
等待型高 load：进程处于 D 状态，通常在等磁盘、NFS 或内核锁。ps -eo stat,wchan 找到等待点，再用 iostat -x 看 %util、await。
cgroup 限流：容器 CPU 配额太低或突发被压。cpu.stat 的 nr_throttled、throttled_usec 持续增长就是证据；调整 limit 或优化突发。
Kubernetes 调度问题：requests/limits 不合理、HPA 指标滞后、节点 allocatable 不足、单 Pod 绑核策略不合适。结合 kubectl top、kubectl describe node 和 metrics-server 判断。

易错点与排错

load average 不是 CPU 使用率：D 状态进程也会推高 load。先看 ps -eo stat，不要直接加 CPU。
容器里的 top 常显示宿主机数据；确认容器 CPU 是否被限流，要看 cgroup 的 cpu.stat，不是宿主机 top。
多线程进程的 %CPU 可以超过 100%；top 默认按进程汇总，按 H 或 top -H 才能看到具体线程。
1 秒采样会漏掉短时尖峰；怀疑瞬时打满时用 perf record、连续 profiler 或更细粒度的指标。
CPU 限流在 top 里看不出来：nr_throttled 增长、应用延迟抖动，往往比 CPU 使用率更能说明问题。
虚拟机里的 %steal 高不是应用能解决的；先确认宿主机或云厂商侧的争抢。
直接 kill 高 CPU 进程会丢失现场；先 perf record -p <pid>、保存线程栈和日志，再决定处置。

参考链接

读完自测

合上页面，先回答，再展开对照。

load average 很高但 CPU 使用率不高，可能是什么原因？先看哪个命令？
容器里 top 看到的是宿主机 CPU，怎样确认容器是否被 cgroup 限流？
用户态高和内核态高，分别应该先查什么？

答案

常见是进程处于 D 状态，在等磁盘、NFS 或内核锁；先看 ps -eo pid,stat,wchan,comm，再用 iostat -x 确认 IO。
看 cgroup v2 的 /sys/fs/cgroup/cpu.stat，重点看 nr_throttled 和 throttled_usec 是否持续增长，并结合 CPU limit 判断。
用户态高先用 perf top 或语言 profiler 找热点函数，pidstat -u 看进程；内核态高先用 mpstat、pidstat -w、sar -n DEV 看系统调用、上下文切换和网络软中断。