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 —— 磁盘空间满或inode耗尽，都会导致大量进程卡在不可中断状态（D状态），直接推高负载
- ss -s —— 看 total established 和 timewait 数量，连接数爆炸或TIME_WAIT堆积过多也会抬升负载
深入一层：揪出具体线程或Java应用热点
如果是Java服务负载高，别只盯着进程级CPU：
- 用 top -Hp [PID] 找到最耗CPU的线程ID（LWP）
- 转成十六进制：printf "%x\n" [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缓存会持续增长，拖慢整个系统响应
基本上就这些。排查不是靠猜，而是按“负载现象 → 资源维度 → 进程粒度 → 线程/代码”逐层收窄。工具只是眼睛，关键在理解每个指标背后的真实含义。
