top可定位90%性能问题，关键看load average（需结合cpu核心数判断）、%cpu(s)分项（us/sy/wa）、进程列表的%cpu/res/time+列，配合m/p/c等快捷键及-b批处理模式精准分析。
直接看 top 输出就能定位 90% 的性能问题，但前提是知道哪几行、哪几列真有用，而不是盯着满屏数字发懵。
怎么看 load average 是不是真高
顶部第一行的 load average: 0.23, 0.14, 0.10 不是 CPU 使用率，而是就绪队列里等待被调度的进程平均数量。它和 CPU 核心数比才有意义：
- 如果服务器是 4 核，
load average长期 > 4，说明任务排队严重，哪怕%Cpu(s)显示空闲也可能卡顿 -
1 min值突增（比如从 0.1 跳到 5.0），大概率是某个进程刚启动或出问题；15 min值也高，说明负载持续存在，不是瞬时抖动 - 负载高但
wa（I/O wait）也高，优先查磁盘或 NFS；如果us+sy接近 100%，才是 CPU 真忙不过来
怎么快速揪出吃 CPU 或内存的进程
默认按 %CPU 降序排列，但实际排查时经常要切视角：
- 按内存看：运行中按
M键，关注RES列（真实物理内存占用），别只看VIRT（虚拟地址空间，含 mmap 和 swap，误导性大） - 确认命令全貌：按
c键，否则COMMAND列只显示进程名（如python），看不到实际执行的是哪个脚本或参数 - 查短命进程：
TIME+小但%CPU高，可能是频繁 fork 的脚本或定时任务；TIME+很大但%CPU低，可能是长期挂起的 Java 进程
为什么 %wa 高却找不到具体进程
%Cpu(s): ... wa: 25.0% 表示 CPU 在等 I/O，但 top 进程列表里 %CPU 列不会体现这个等待——因为进程此时不消耗 CPU 时间。这时要：
- 先用
iostat -x 1确认是哪块盘%util接近 100% 或await异常高 - 再用
pidstat -d 1查具体进程的读写 BPS 和 I/O wait 时间 -
top里只能辅助判断：如果多个进程S状态（睡眠）且RES占用不小，又伴随高wa，基本就是它们在等磁盘响应
批处理场景下怎么避免交互式陷阱
写监控脚本或日志采集时，别用默认交互模式：
- 加
-b（batch）+-n 1获取单次快照：top -b -n 1 | head -20 - 想按内存排序导出：用
-o %MEM而不是靠交互按键，top -b -n 1 -o %MEM | head -15 - 注意
-d设置刷新间隔，但批处理下无效；真正影响输出的是-n次数，设为 1 最安全 - 别漏
-c：没它，COMMAND列在批处理里照样只截断，看不出完整路径
最易忽略的其实是单位混淆：KiB Mem 是 KiB（1024 进制），而有些旧版 top 显示 MiB，数值差一倍；还有人把 SHR 当成可释放内存，其实它包含代码段和共享库，不能简单减去。
