Linux 系统负载突增的排查顺序

判断系统是否真过载需先用nproc查CPU核数，再结合load average三值（尤其15分钟值是否持续＞核数×1.2）、top中%Cpu(s)的wa/id占比；再依us+sy高/r大→CPU问题、wa高/%util≈100%→IO瓶颈、free为0→内存不足；最后用pidstat、lsof、slabtop等定位隐蔽负载源。

看 load average 和 CPU 核心数是否真过载

别一看到 load average: 12.5, 8.3, 4.1 就慌——先执行 nproc 看实际 CPU 核数。16 核机器 load=12.5 是正常波动；但 load=50 就明显排队了。关键看 15 分钟值（第三个数）是否持续 > 核数 × 1.2，再结合 top 右上角的 %Cpu(s)：如果 wa > 20% 或 id ≈ 0，基本可排除纯 CPU 问题，转向 IO。

区分是 CPU 高、IO 高还是内存压垮了系统

用 top 中三类指标快速分路：

• us + sy 高且 r（运行队列）持续 > 核数 → CPU 密集型，进 top -Hp [PID] 找线程
• wa 高 + %util 接近 100%（用 iostat -xz 1 验证）→ IO 瓶颈，立刻 sudo iotop -o
• free -h 显示 available vmstat 1 中 si/so > 0 → 内存不足引发 swap，查 dmesg | grep oom 看有没有进程被杀

绕过 top 默认排序，直击真实“搞事进程”

很多高负载不是由单个 CPU 大户引起，而是多个小进程或内核资源争用：

• 查 IO 暴力户：pidstat -d 1 比 iotop 更稳，尤其在终端卡顿时仍能输出每秒读写 KB
• 查文件句柄疯长：lsof -nPl | awk '{print $2}' | sort | uniq -c | sort -nr | head -10，常暴露日志轮转失败或连接泄漏
• 查 dentry 缓存暴涨：slabtop -o | grep -E 'dentry|inode_cache'，大量小文件操作（如频繁 stat）会推高此项，导致系统级延迟

java 进程 CPU 高时，别只 dump stack 就完事

拿到线程 tid 后转十六进制、jstack [PID] | grep -A 20 "0x..." 是基础，但容易漏掉 GC 压力：

• 先跑 jstat -gcutil [PID] 1000，如果 OU（老年代使用率）持续 > 85% 或 YGC 频次 > 10/s，说明对象堆积才是根因
• 再补一手 jmap -histo [PID] | head -20，重点看 java.lang.String、byte[]、HashMap$Node 是否异常多——往往是缓存未设上限或日志拼接滥用
• 注意：jstack 输出里若全是 parking to wait for，大概率是锁竞争，不是代码逻辑问题，得看 java.util.concurrent 相关调用栈

真正难排查的，往往不是那个占 90% CPU 的 Java 进程，而是十几个各占 5% 的 python 脚本同时刷磁盘，或者 NFS 挂载点卡住后堆积的几十个 D 状态进程——它们不会出现在 top CPU 排序里，但会让 load 平均值飙到离谱数字。