Linux 系统负载高≠CPU 满载，它表示“运行 + 等待运行”进程的平均数；需结合 CPU 核心数（如 8 核）判断：负载超 8 需关注，超 16 须紧急排查，若负载 5 但 CPU 使用率仅 30% 则多为 I / O 瓶颈。
Linux 系统负载高，不等于 CPU 跑满了——它反映的是“正在运行 + 等待运行”的进程总数平均值。真正要稳住系统，得先分清是 CPU 真忙、磁盘在拖后腿、内存快见底，还是网络或内核调度出了问题。
看懂负载数字和 CPU 核心数的关系
用 uptime 或 cat /proc/loadavg 查三个负载值（1/5/15 分钟），再用 nproc 或 grep -c processor /proc/cpuinfo 知道逻辑 CPU 个数。比如 8 核机器，负载长期超过 8 就说明排队进程变多；超过 16 就得马上查；但若负载 5 而 CPU 使用率才 30%，大概率是 I / O 卡住了，不是 CPU 不够用。
快速定位瓶颈在哪一类资源
按顺序执行这几个命令，别跳步：
- top —— 按 1 看各 CPU 核负载，按 P 排序看 CPU 占用最高的进程
- iostat -x 1 —— 关注 %util（接近 100% 表示磁盘饱和）、await（单次 IO 等待毫秒数，超 10ms 需警惕）、r/s w/s（读写 IOPS 是否突增）
- free -h —— 看 available 是否持续偏低；再配合 ps -eo pid,ppid,cmd,%mem –sort=-%mem | head 找吃内存大户
- df -h && df -i —— 磁盘空间满或 i node耗尽，都会导致大量进程卡在不可中断状态（D 状态），直接推高负载
- ss -s —— 看 total established 和 timewait 数量，连接数爆炸或 TIME_WAIT 堆积过多也会抬升负载
深入一层：揪出具体线程或 Java 应用 热点
如果是 Java 服务负载高，别只盯着进程级 CPU：
- 用 top -Hp [PID] 找到最耗 CPU 的线程 ID（LWP）
- 转成十六进制：printf “%xn” [LWP]
- 导出堆 栈：jstack [PID] | grep -A 20 “0x[hex]”，直接定位到锁竞争、死循环或低效时间格式化等典型问题
- 更省事可用 show-busy-java-threads.sh（开源脚本），一键输出 TOP 10 繁忙线程及对应代码行
别漏掉内核和日志里的关键线索
很多高负载不是业务代码导致的，而是系统层异常：
- dmesg -T | tail -30 —— 查 OOM killer 是否杀过进程、是否有硬件报错或驱动异常
- journalctl -S “2 hours ago” | grep -i “error|warn|throttle” —— 看最近两小时有无内核警告、存储链路重试、NFS 挂起等
- vmstat 1 5 —— 关注 cs（上下文切换次数）是否异常高，过高说明进程 / 线程频繁抢 CPU，可能由锁争用或轮询引起
- slabtop —— 内核内存泄漏时，某些 slab 缓存会持续增长，拖慢整个系统响应
基本上就这些。排查不是靠猜，而是按“负载现象 → 资源维度 → 进程粒度 → 线程 / 代码”逐层收窄。工具 只是眼睛，关键在理解每个指标背后的真实含义。
