load average 高不等于 cpu 忙：它统计可运行和不可中断（d状态）进程数；若 r 值小但 load 高，多为 i/o 卡住导致 d 进程堆积，需用 ps 查 d 进程并定位阻塞设备。
怎么看 load average 是真高还是假警报
平均负载高不等于 CPU 忙——它统计的是「可运行 + 不可中断（D 状态）」进程数，和 CPU 利用率没有直接换算关系。比如一个进程卡在磁盘 I/O 上（D 状态），它会拉高 load，但 %us 和 %sy 可能都很低。
- 先跑
uptime或看top右上角：如果load average> 逻辑 CPU 数（grep -c processor /proc/cpuinfo），才值得往下查 - 再看
vmstat 1的r列：它只统计等待 CPU 的进程数（不含 D 状态）。如果r长期 > CPU 核数，才是真 CPU 饱和；如果r很小但 load 很高，大概率是 I/O 卡住了一堆进程（D状态） - 用
ps aux | awk '$8 ~ /^D/ {print}'快速揪出 D 状态进程，再结合lsof -p PID或cat /proc/PID/stack看它卡在哪类设备上
怎么区分是用户态狂占 CPU 还是内核在瞎忙
top 或 mpstat -P ALL 1 输出里的 %us、%sy、%iowait 是关键分水岭。三者加起来远不到 100%？那可能是 steal（虚拟机被抢）、idle 太高，或者采样太短没抓到峰值。
-
%us高 + 某个进程%CPU接近 100% → 典型业务逻辑或算法瓶颈，盯死ps aux --sort=-%cpu | head -n5 -
%sy高（>20%）且%us不高 → 内核开销异常，常见于高频系统调用（如read/write小包）、锁竞争、软中断堆积（/proc/interrupts里看NET_RX或irqbalance是否失衡） -
%iowait高（>10%）→ 别急着优化代码，先确认是不是磁盘真慢：iostat -xz 1看%util是否持续 >90%，await是否飙升；如果是 NVMe 盘却%util很低但await高，可能是队列深度或 I/O 调度器问题
为什么 top 里看到的 CPU 占比和 mpstat 对不上
top 默认按进程维度聚合，且采样周期不固定；mpstat 是内核级精确采样，还能分核查看。更关键的是：默认 top 显示的是“所有 CPU 时间占比”，而 mpstat -P ALL 的 all 行是加权平均，单核行才是真实值——很多核空闲、一两个核 100%，top 会显示成“50%”，但实际是严重不均衡。
- 查核间不均衡必须用
mpstat -P ALL 1，看各 CPU 行的%usr是否差异巨大（比如 CPU0 99%、CPU7 2%） - 如果发现某核长期满载，用
pidstat -t -p PID 1查该进程线程绑核情况；再用taskset -cp PID确认是否被错误绑核 - 别信
top右上角那个 “Cpu(s): …” 总览，它掩盖了不均衡；也别在排查时开一堆 GUI 工具（如htop、gnome-system-monitor），它们自己就吃 CPU
steal 高了到底要不要马上扩容
%steal 高说明宿主机 CPU 被其他虚拟机抢走了——但这不一定是你的锅，也不一定立刻要扩容。云厂商的超卖策略下，短时 %steal 波动（10% 才值得警惕。
- 先排除本机干扰：用
perf top -e 'syscalls:sys_enter_*'看有没有异常高频系统调用（比如疯狂epoll_wait），这类行为在虚拟化下会被放大 steal - 对比同批次实例：如果只有你这台
%steal异常高，可能是宿主机故障，联系云厂商换宿主；如果整批都高，大概率是资源池过载，扩容才有意义 - 别盲目调
vm.swappiness或关kswapd来“省 CPU”，steal 是调度层问题，内存参数改了也没用
真正难的不是看懂数字，而是把 %iowait 高和磁盘慢划等号、把 load 高当成 CPU 忙、把 %steal 当成自己代码问题——这些归因错误，比工具不会用更致命。
