uptime末尾三个数字是1/5/15分钟系统负载平均值，表示单位时间内处于R或D状态的进程平均数量，需结合CPU核心数判断是否异常：4核机器load达8.2、7.5、6.9即持续超载。
直接看 uptime 就能知道负载是否异常
不用把一堆工具挨个打开，uptime 这一行输出就已经把最关键的三个负载值摆在眼前了：1分钟、5分钟、15分钟平均负载。它不会直接告诉你到底是哪个进程在“捣乱”，但足够让你第一时间判断——这台机器要不要马上处理。如果 load a verage: 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% 且id< 5%，大概率是某个用户进程吃满 CPU，按P排序找 top 进程- 按
1键可展开多核视图，避免把单核打满当成整体负载高
用 vmstat 1 看上下文切换和阻塞源头
vmstat 1 每秒刷新一次，比 top 更适合观察波动。重点关注三列：
cs（context switch）：每秒上下文切换次数，>10w 往往意味着大量短生命周期进程或线程争抢 CPUin（interrupts）：中断频率，异常升高可能指向硬件问题（如网卡、磁盘故障）wa和r（runnable 进程数）：如果r长期 > 逻辑核心数，而wa也高，基本锁定是 I/O 设备拖慢了整个调度队列
别只盯着 load a verage，cat /proc/loada vg 多出的两个字段很关键
cat /proc/loada vg 输出形如 2.45 2.11 1.98 3/512 12345，最后两个数常被忽略：
3/512：当前运行队列中活跃进程数 / 总进程数。若第一个数远大于逻辑核心数（比如 16/512 在 4 核机器上），说明大量进程在排队等 CPU12345：最近创建的进程 PID，结合ps -p 12345 -o pid,tid,comm,etime可快速定位突发负载来源
真正难缠的问题往往藏在这两个字段里——比如一个 fork 冲击波刚启动时，load a verage 还没拉高，但 r 值和 /proc/loada vg 第二段已经飙升。
