负载值是“正在运行+等待运行”的进程平均数，非CPU使用率；需结合CPU核心数判断：≤0.7较空闲，>1已过载，远高于核心数则存在严重阻塞。
看懂负载值和CPU核心数的关系
执行 uptime 或 cat /proc/loadavg，会看到三个数字，比如 2.45 1.98 1.72，分别代表过去 1 分钟、5 分钟、15 分钟的平均负载。这个数值不是 CPU 使用率，而是“正在运行 + 等待运行”的进程平均数量。
用 nproc 或 grep -c 'processor' /proc/cpuinfo 查出逻辑 CPU 核心数（比如 8 核）。关键判断标准是：
– 负载值 ÷ CPU 核心数 ≤ 0.7：系统较空闲
– 负载值 ÷ CPU 核心数 > 1：已过载，需干预
– 负载值远高于核心数（如 16 核机器负载达 30+）：存在严重阻塞或资源争抢
分方向快速定位瓶颈类型
负载高 ≠ CPU 忙。可能是 CPU、内存、磁盘 I/O 或中断在拖慢系统。按以下顺序快速筛查：
- CPU 是否真忙？ 运行 top，关注第三行 %Cpu(s)：若 us + sy 持续 > 80%，说明用户或内核代码在大量消耗 CPU；若 wa 高（>20%），说明进程卡在等磁盘，实际 CPU 是空闲的
- 有没有进程疯占 CPU？ 在 top 中按 Shift+P 排序，看前几位 %CPU 是否异常（如单个进程长期 >300%）；再用 ps -eo pid,ppid,cmd,%cpu --sort=-%cpu | head -10 精确输出
- 磁盘是不是堵了？ 执行 iostat -x 1 3，重点关注 %util（接近 100% 表示磁盘饱和）、await（单次 I/O 平均耗时，>20ms 值得警惕）、r/s w/s（读写频次是否突增）
- 内存是否快见底或触发 OOM？ free -h 看可用内存和 available 列；dmesg | grep -i "killed process" 检查是否被内核杀过进程；slabtop 查内核对象内存占用是否异常膨胀
深入线程与 Java 进程排查（适用常见服务场景）
当确认是某个 Java 或多线程服务导致高负载，不能只停在进程层：
- 用 top -Hp [PID] 查该进程下哪些线程 CPU 占用最高，记下 TID（十进制）
- 把 TID 转成十六进制：printf "%x\n" [TID]（例如 12345 → 3039）
- 导出线程堆栈：jstack [PID] | grep -A 20 "0x3039"，直接定位到具体方法栈帧
- 更省事的方式是用封装脚本：show-busy-java-threads.sh -c 5 -s 1000，自动找出最忙的 5 个线程并打印堆栈
- 配合 jstat -gcutil [PID] 1000 观察 GC 是否频繁（S0/S1/E/U/O 持续跳变、YGC/FGC 次数陡增），避免误判为 CPU 问题实为 GC 停顿
别忽略日志、中断和软硬件协同因素
有些高负载藏得深，需要跳出常规资源视图：
- 查内核中断压力：cat /proc/interrupts | sort -k2 -nr | head -10，看是否有某 CPU 上硬中断（如网卡 rx）远超其他核，可能网卡绑定不均或被打满
- 查软中断：mpstat -P ALL 1 3 中看 %soft 是否持续高，常出现在高并发网络收发或定时器密集场景
- 翻系统日志：journalctl -S "2 hours ago" | grep -i "error\|warn\|throttle"，特别留意 storage、nvme、ata 相关报错，硬盘掉盘或固件 bug 可能引发持续 I/O hang
- 检查硬件基础：sudo smartctl -a /dev/sda（看磁盘健康）、sensors（看 CPU 温度是否过热降频）、dmidecode -t memory（确认内存插槽和速率匹配）
基本上就这些。排查不是靠一个命令定乾坤，而是用一组命令交叉验证——比如 load 高 + wa 高 + iostat %util 100% + iotop 显示某进程写盘猛，就能闭环归因为磁盘瓶颈。稳住节奏，一层层剥，问题自然浮出来。
