应优先看 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 <pid>：若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 里它的写入速率可能占满磁盘带宽。别只信第一眼看到的数字。
