负载是否真高需先除以cpu核数判断；再结合%wa、iostat、strace等区分cpu/i/o瓶颈；关注available内存而非free；排除d状态进程、句柄泄漏及内核/硬件问题。
怎么看负载是不是真高
别一看到 load average: 5.2, 4.8, 3.1 就慌——得先除以 CPU 核数。运行 nproc 或 grep -c processor /proc/cpuinfo 确认逻辑核数，比如是 4 核，那 1 分钟负载 5.2 ÷ 4 = 1.3，说明已有排队；但如果是 16 核，1.3 就完全正常。
容易踩的坑：
- 把
uptime里的三个值当成“越来越严重”：其实 15 分钟值低、1 分钟值高，恰恰说明是刚爆发的新压力，要立刻盯进程，而不是等它自己回落 - 忽略 D 状态进程：
ps aux | awk '$8 ~ /D/ {print}'能筛出不可中断睡眠的进程，它们不占%CPU却推高 load，常因 NFS 挂载卡死或磁盘响应超时导致 - 误判“负载=CPU 使用率”：load 高但
%us和%sy都很低，%wa却飙到 60%，那问题根本不在 CPU，而在 I/O
怎么快速分清是 CPU 还是 I/O 瓶颈
打开 top 后别只盯着 %CPU 列排序——先看顶部的 %Cpu(s) 行：us 高 → 用户态计算密集；sy 高 → 频繁系统调用（如大量 fork、epoll_wait）；wa 高 → CPU 在干等磁盘或网络返回。
实操建议：
-
vmstat 1 5看r（就绪队列长度）和wa：若r长期 > CPU 核数 且wa> 10%，基本锁定 I/O -
iostat -x 1 3关键看%util和await：%util > 90%表示设备饱和；await > 10ms表示单次 I/O 响应慢，可能是磁盘老化、RAID 卡缓存关闭、或云盘 IOPS 配额打满 - 如果
%wa高但iostat显示磁盘一切正常？立刻查网络：用iftop -P tcp或nethogs看是否有进程在疯狂发包或建连接
怎么精准定位到具体线程或系统调用
找到高消耗进程 PID 后，下一步不是直接 kill，而是确认它到底在干什么。Java 应用尤其容易卡在某个线程里，光看进程级 CPU 占用会漏掉热点。
实操建议：
- 查线程级 CPU：
top -Hp <pid></pid>，按P排序，记下高占用线程的 TID - Java 进程要把 TID 转成十六进制：
printf "%x\n" <tid></tid>，再用jstack <pid> | grep -A10 <hex_tid></hex_tid></pid>定位堆栈，看是不是死循环、正则回溯、或 synchronized 锁争抢 - 通用追踪：
strace -tt -T -p <pid> -o /tmp/trace.log</pid>，重点观察是否卡在read、futex、epoll_wait上——卡在futex通常意味着锁竞争；卡在read且没返回，可能后端服务无响应或 socket 缓冲区堵死 - 别忘了检查文件句柄：
lsof -p <pid> | wc -l</pid>，超过系统限制（如 65535）会导致新建连接失败、日志写不进，表现为“看起来没报错但功能异常”
为什么 free -h 的 available 比 free 更关键
很多人看到 free 列显示还有 200MB 就觉得内存够用，结果 available 只剩 30MB，系统已经开始频繁触发 kswapd 或 OOM Killer。
原因很简单：free 是当前未被任何进程使用的物理内存，而 available 是内核估算出的、能在不触发 swap 的前提下还能分配给新进程的内存量，它已扣除 page cache 中难以回收的部分（比如 dirty page、mmap 映射页）。
容易被忽略的点：
-
dmesg | grep -i "killed process"必须查——哪怕available没归零，只要某次内存分配请求无法满足，OOM Killer 就会按评分杀掉进程，日志里留痕但业务可能已丢数据 -
buff/cache高 ≠ 内存紧张：Linux 会主动用空闲内存做缓存，只要available充足，这是健康行为；但若available持续低于总内存 10%，且vmstat中si/so不为 0，才是真缺内存 - 某些容器环境（如 Docker）中，
available计算受 cgroup memory limit 影响，free -h看的是宿主机视角，需配合cat /sys/fs/cgroup/memory/memory.usage_in_bytes对齐
最麻烦的情况，是 load 高、CPU 使用率不高、I/O 看不出异常、内存也够——这时候得怀疑是不是内核模块 bug、硬件故障（如内存 ECC 报错）、或者 hypervisor 层资源争抢。这些没法靠几个命令秒定，但至少能帮你排除掉 90% 的常见误判。
