Linux高负载需按“负载值→资源类型→进程→线程→调用链”逐层排查：先比对负载与CPU核心数（阈值=核数×0.7），再用mpstat/iostat/pidstat区分CPU型或I/O型，接着用strace/jstack定位线程级瓶颈，最后检查内存与swap影响。
Linux高负载不是“CPU用满了”那么简单——它反映的是系统整体任务队列的积压程度。真正关键的是：先看负载值是否越界，再分清是CPU忙、IO堵、内存缺，还是进程卡在系统调用里。定位准了，修复才快。
一、确认负载是否真超标
别只盯着uptime或top里那个数字。先查CPU核心数：
-
grep -c 'processor' /proc/cpuinfo或nproc - 合理阈值 = 核心数 × 0.7（比如8核，负载持续＞5.6就要查）
- 重点看三个值：
load average: 12.4, 9.8, 7.2—— 若1分钟值远高于15分钟值，说明突发尖峰；若三者都高且平稳，大概率是长期瓶颈
二、区分负载类型：CPU型 vs I/O型
高负载但CPU使用率低？大概率是I/O卡住了。反过来，CPU使用率飙高+负载高，才是计算密集问题。
jm-jsjkxyjs02-zlm-405
下载
使用约定式提交（Conventional Commits）生成标准化的 Git 提交信息。适用于以下场景： (1) 暂存更改时需要提交信息； (2) 审查 diff 时希望获得结构化摘要； (3) 编写 PR 描述或变更日志（changelog）条目； (4) 用户明确要求“为本次更改编写提交信息”。 该功能会分析已暂存/未暂存的 diff，并生成按类型（type）划分范围的提交信息。
- CPU型：用
mpstat -P ALL 1 3看各核%idle是否接近0；再用pidstat -u 1找出%CPU最高的进程 - I/O型：用
iostat -x 1 3看%util是否持续＞90%，同时%wa（iowait）是否＞10%；再用iotop -o找实际在刷盘的进程 - 混合型：
pidstat -u 1 -d 1可同时输出CPU和IO指标，一眼比对
三、快速定位“元凶”进程
找到高消耗进程只是第一步，得往下挖一层——是哪个线程、哪段代码、甚至哪个系统调用在拖慢它。
- 对Java进程：用
top -Hp [PID]找到高CPU线程TID，转成十六进制（printf "%x\n" [TID]），再用jstack [PID] | grep -A10 [hex]定位堆栈 - 对任意进程：用
strace -p [PID] -tt -T -f -o /tmp/trace.log捕获系统调用耗时，重点关注反复出现的read、write、futex、epoll_wait等长耗时调用 - 如果进程卡在D状态（不可中断睡眠），基本可断定是磁盘或驱动层问题，
ls /proc/[PID]/stack能看到内核栈
四、别忽略内存与交换的影响
表面看是CPU或IO问题，背后常是内存不足触发了OOM Killer或频繁swap，导致大量进程排队等待页回收。
- 用
free -h看available是否严重偏低；用cat /proc/meminfo | grep -E "^(MemAvailable|SwapTotal|SwapFree|PageIn|PageOut)"查交换活动 - 运行
dmesg -T | grep -i "killed process"确认是否有进程被OOM Killer干掉 - 观察
vmstat 1 5中的si/so（swap in/out）和pgmajfault（主缺页次数），若数值持续非零，说明内存压力真实存在
基本上就这些。排查不是靠猜，而是按“负载值→资源类型→进程→线程→调用链”逐层收窄。工具不用全记，但mpstat、iostat、pidstat、strace这四个组合，覆盖90%的高负载场景。
