uptime末尾三个数字是1/5/15分钟系统负载平均值，表示单位时间内处于R或D状态的进程平均数量，需结合CPU核心数判断是否异常：4核机器load达8.2、7.5、6.9即持续超载。
直接看 uptime 就能知道负载是否异常
不用打开一堆工具，uptime 一行输出就包含最关键的三个负载值：1分钟、5分钟、15分钟平均负载。它不告诉你哪个进程在作怪，但能立刻判断“要不要马上动手”。如果 load average: 8.2, 7.5, 6.9 出现在一台 4 核 CPU 的机器上，说明系统已持续超载——因为理想上限是逻辑核心数（不是物理核数），查法：grep 'model name' /proc/cpuinfo | wc -l。
top 里看实时负载 + CPU 状态分布
top 启动后第一行和 uptime 一样显示负载，第三行才是重点：us（用户态）、sy（内核态）、wa（I/O 等待）、id（空闲）这些百分比加起来接近 100% 才可信。常见误判点：
-
wa高但id也高？说明 CPU 没瓶颈，真正卡在磁盘或网络响应上 -
us持续 >80% 且idP 排序找 top 进程 - 按
1键可展开多核视图，避免把单核打满当成整体负载高
用 vmstat 1 看上下文切换和阻塞源头
vmstat 1 每秒刷新一次，比 top 更适合观察波动。重点关注三列：
-
cs（context switch）：每秒上下文切换次数，>10w 往往意味着大量短生命周期进程或线程争抢 CPU -
in（interrupts）：中断频率，异常升高可能指向硬件问题（如网卡、磁盘故障） -
wa和r（runnable 进程数）：如果r长期 > 逻辑核心数，而wa也高，基本锁定是 I/O 设备拖慢了整个调度队列
别只盯着 load average，cat /proc/loadavg 多出的两个字段很关键
cat /proc/loadavg 输出形如 2.45 2.11 1.98 3/512 12345，最后两个数常被忽略：
-
3/512：当前运行队列中活跃进程数 / 总进程数。若第一个数远大于逻辑核心数（比如 16/512 在 4 核机器上），说明大量进程在排队等 CPU -
12345：最近创建的进程 PID，结合ps -p 12345 -o pid,tid,comm,etime可快速定位突发负载来源
真正难缠的问题往往藏在这两个字段里——比如一个 fork 炸弹刚启动时，load average 还没拉高，但 r 值和 /proc/loadavg 第二段已经飙升。
