怎么看 load average 是否异常
系统负载值（load average）不是 CPU 使用率，而是「就绪态 + 不可中断态（D 状态）进程的平均数量」。它反映的是排队等待被调度的“活任务”有多少。判断是否异常，必须结合逻辑 CPU 核数：
— 运行 grep -c 'model name' /proc/cpuinfo 得到核数（比如 4）；
— 若 15 分钟负载（第三个数）持续 > 核数 × 1.5，就该排查了；
— 单核机器上 load average: 2.3, 3.1, 4.0 是明显过载；四核机器上 3.8, 4.2, 4.5 属于临界，但 6.0, 7.2, 8.1 就已超负荷。
常见误区：只看第一个数（1 分钟），但它波动大，容易误判；重点盯 5 分钟和 15 分钟值。
top 第二行 Tasks 的真实含义
Tasks: 133 total, 2 running, 130 sleeping, 0 stopped, 0 zombie 这行里，“running” 并不等于“正在占用 CPU”，而是指处于 R 状态（runnable）——即已就绪、正排队等 CPU 调度；“sleeping” 也分两种：S（可中断睡眠，比如等键盘输入）和 D（不可中断睡眠，比如等磁盘 I/O），只有 D 状态才会推高 load average。
— zombie 进程不占资源但会泄漏 PID，积多可能影响新进程创建；
— stopped 多是被 Ctrl+Z 暂停的作业，用 jobs 和 fg 可恢复；
— 如果 running 长期为 0，但系统卡顿，大概率是大量进程卡在 D 状态（查 iostat -x 1 看 await、%util）。
%Cpu(s) 各字段怎么对应真实瓶颈
%Cpu(s): 0.2us, 0.1sy, 0.0ni, 99.6id, 0.0wa, 0.0hi, 0.0si, 0.0st 中：
— us 高 → 用户态程序（如 Python、Java 应用）吃 CPU；
— sy 高 → 内核态开销大，常见于频繁系统调用（如大量小文件读写、线程切换）；
— wa > 10% → I/O 等待严重，磁盘或网络存储拖慢整体；
— st（steal time）> 5% → 虚拟机被宿主机“抢走”太多 CPU，需联系云厂商或调低虚拟机配额；
注意：id 高不代表系统空闲——如果 wa 同时也很高，说明 CPU 在干等 I/O，实际是 I/O 瓶颈。
别依赖默认 top，几个必改交互操作
刚敲 top 进去，默认视图信息密度低、排序不合理：
— 按 1 键显示每个 CPU 核心使用率（SMP 下非常关键）；
— 按 M 切换到内存排序，快速定位内存大户（注意看 %MEM 列，不是 VIRT）；
— 按 c 显示完整命令行，否则看不到 Java 的 -Xmx 参数或 Python 的脚本路径；
— 按 u 输入用户名，过滤掉无关用户进程（比如只看 www-data）；
— 按 k 杀进程前务必先看 PID 和 USER，避免误杀 systemd 或数据库主进程。
load average 的数值本身不告诉你哪个进程在捣鬼，它只是个“警报灯”。真正定位问题，得从它出发，再用 ps aux --sort=-%cpu | head -10、pidstat -d 1 或 iotop 往下挖——这个衔接步骤，90% 的人会跳过去直接重启服务。
