Linux高负载排查需先定性再定位：一看load与CPU核数关系判断是否真告警；二用top看wa和D状态定CPU或IO型瓶颈；三用top-jstack查Java热点线程；四查swap、inode、网络连接及slab泄漏等隐形负载源。
Linux高负载排查不是看一个数字就下结论，关键得拆开看：负载高是真忙，还是“假忙”——比如CPU空闲但load飙高，那八成是I/O卡住了。核心思路就一条：先定性（CPU型？IO型？内存型？），再定位（哪个进程/线程/设备在拖后腿），最后收口（日志、堆栈、资源配比都要留痕）。
一看负载值和CPU核心数的关系
执行 uptime 或 cat /proc/loadavg，拿到三个数字（1/5/15分钟平均负载）。立刻用 nproc 查出当前CPU逻辑核数。如果 1分钟load > CPU核数 × 1.5，且持续2分钟以上，才算真正告警。比如8核机器load到14，就得动手；但load=9.2只是略高，先别急着杀进程——可能只是短时抖动。
- load ≈ CPU核数：系统轻载，基本健康
- load 是核数的2倍以上：大概率有瓶颈，需深入
- load很高但%us + %sy总和长期低于30%：重点查I/O或不可中断睡眠（D状态进程）
二分法快速定性：CPU高 or IO高
运行 top，盯住右上角两行关键指标：
– %Cpu(s) 行里的 us（用户态）、sy（内核态）、wa（I/O等待）
– Tasks 行里的 D（不可中断睡眠）数量
- 如果 wa > 20% 或 D状态进程 > 5个：直接跳去查磁盘I/O（iostat -x 1 3 看%util和await）
- 如果 us + sy > 80% 且 wa ：说明CPU真被吃满，用 top -o %CPU 找罪魁进程
- 如果 us低、sy高、wa也高：可能是大量系统调用+磁盘争抢，常见于小文件随机读写或元数据操作频繁场景
三步锁定Java类应用的热点线程
很多高负载来自Java服务——CPU跑满但业务没流量，往往是死循环或GC风暴。按顺序做：
- 用 top -p [PID] 确认该Java进程CPU占比异常
- 用 top -Hp [PID] 找出占用最高的线程TID（十进制）
- 转成十六进制：printf "%x\n" [TID]，再用 jstack [PID] | grep -A30 [16进制值] 定位堆栈——重点关注 RUNNABLE 状态下反复调用同一方法的位置
注意：jstack输出前最好加 -l（显示锁信息）和 -e（显示额外线程信息），避免漏掉阻塞线索。
四类常被忽略但高频的“隐形负载源”
有些负载不体现在top里，却实实在在拖垮系统：
- 内存不足触发swap：看 free -h 的available是否远低于total，同时 vmstat 1 中 si/so 列持续非零
- inode耗尽：df -i 查使用率，100%会导致新建文件失败、日志写不进、容器起不来
- 网络连接打满：ss -s 看 total established 是否接近 net.core.somaxconn 设置值，或 TIME-WAIT 过多
- 内核slab泄漏：slabtop -o 排序看 cache 占用，如 dentry、inode_cache 持续上涨，可能是程序未正确关闭文件描述符
基本上就这些。不复杂但容易忽略——多数线上高负载问题，靠这四步就能在10分钟内圈出根因。
