Linux 资源瓶颈的系统化判断方法

应优先看 load average 判断系统负载是否越界，而非仅盯 CPU%，因 load average 反映运行或不可中断睡眠进程数均值，与 CPU 核心数对标；再结合 %us、%sy、%wa 区分根因，辅以 vmstat、iostat、pidstat 等工具定位真实瓶颈。

看 load average 是否越界，而不是只盯 CPU%

很多人一上来就 top，盯着 %Cpu(s): 95.0 us 大呼“CPU打满了”，结果发现负载其实不高——这是典型误判。linux 的 load average（由 uptime 或 top 首行给出）才是真正反映系统“忙不忙”的宏观指标：它统计的是 **正在运行（R）或不可中断睡眠（D）的进程总数均值**，和 CPU 核心数直接对标。

• 单核机器：load > 1.0 就算承压；4 核机器：> 4.0 才需警惕
• 若 load average: 12.3, 11.9, 10.1 而 mpstat -P ALL 1 显示各核 %idle 都在 30%+，那大概率是大量进程卡在磁盘 I/O（D 状态），不是 CPU 真被算满
• 注意 1/5/15 分钟三值趋势：若 1 分钟值远高于 15 分钟，说明突发压力刚来，别急着扩容；若三值持续高位，才是真瓶颈

区分 %us、%sy、%wa —— 它们指向完全不同的根因

top 第二行的 CPU 使用率三元组，是诊断方向的分水岭：

• %us 高（比如 >70%）且集中在某几个用户进程 → 很可能是业务逻辑计算密集（如 python 循环处理大数据、java GC 压力大），该查代码或 jvm 参数
• %sy 高（>20%）→ 内核开销过大：常见于高频系统调用（strace -p PID 可验证）、网络软中断堆积（/proc/interrupts 查 NIC 中断分布）、或容器内 cgroups 频繁限流触发调度
• %wa 高（>15%）→ 不是“CPU 慢”，而是“CPU 在等磁盘”。此时 iostat -dx 1 必须跟上：若 %util ≥ 95% 且 await > 10ms（HDD）或 > 1ms（SSD），就是磁盘 I/O 瓶颈；但若 %util 很低而 %wa 高，反而可能是存储后端（如 NFS、ceph）延迟高或路径故障

内存瓶颈的关键证据不是 free 少，而是 si/so 和 OOM Killer 日志

free -h 里 available 值低只是预警信号，真正坐实内存瓶颈得看动态行为：

• 执行 vmstat 1 5，紧盯 si（swap-in）和 so（swap-out）列：只要连续几秒非零，说明物理内存已不够，内核正疯狂换页，性能必然断崖下跌
• dmesg -T | grep -i "killed process" 若有输出，代表 OOM Killer 已动手杀进程——这不是“内存紧张”，是“内存耗尽”的铁证，必须立刻查 smem -r -c "pid user comm pss" 找 PSS 最大的嫌疑进程
• Java 应用要额外跑 jstat -gcutil ：若 O（老年代）使用率长期 >90% 且 FGCT（Full GC 次数）飙升，是 JVM 堆配置或泄漏问题，和系统内存无关

用 pidstat 和 iotop 锁定“真凶进程”，而非只看 top 排名

top 默认按 CPU% 排序，但很多瓶颈进程根本不上榜：比如一个进程 CPU% 只有 5%，却每秒发起 10 万次小文件读写，iostat 会显示磁盘狂转，top 却看不出异常。

• 查 CPU 真凶：pidstat -u 1 3（每秒采样 3 次），比 top 更稳，避免瞬时抖动干扰；对多线程进程，加 -t 参数看线程级分布
• 查 I/O 真凶：iotop -o（只显示实际在做 I/O 的进程），配合 iotop -P 看每个进程的读写速率（B/s）和 IOPS，比 ps aux --sort=-%mem 有效得多
• 查网络真凶：ss -tulnp 快速定位监听端口和所属进程；nethogs（需安装）可按进程实时显示上下行带宽，专治偷偷上传日志或同步数据的后台程序

真正的瓶颈往往藏在“看起来很安静”的进程背后——比如一个 rsync 进程在后台缓慢同步百G文件，%CPU 不高，但 iotop 里它的写入速率可能占满磁盘带宽。别只信第一眼看到的数字。