top 显示的 %CPU 超过 100% 是因按所有逻辑 CPU 核心累计计算，如 4 核满载显示 400%；需用 1 键查 per-CPU 负载，Shift+P 排序但注意是瞬时值；RES 与 %MEM 不一致源于未考虑 cgroups、共享内存等；应启用 SWAP/CODE 列，结合 free -h 区分缓存与泄漏；用 top -d 0.5 -n 1 或 watch -n 0.5 'top -bn1 | head -20' 提升采样精度；%wa 仅在顶部显示，I/O 阻塞需配合 iostat -x 1 和 iotop；深层问题需 perf top 或 eBPF 工具定位。
top 不是“看个 CPU 占用那么简单”——它默认展示的其实是 ps 风格的快照，且关键指标（如 %CPU 累计值、内存真实可用量）容易被误解。必须调整视图、理解字段含义、避开采样陷阱，才能用于真实问题定位。
为什么 top 显示的 %CPU 经常超过 100%？
Linux 的 %CPU 是按所有逻辑 CPU 核心累计计算的：单线程满载 1 个核心显示 100%，4 核机器上 4 个线程并行满载就显示 400%。这不是错误，而是设计如此。
- 按
1键可切换是否显示每个核心单独负载（进入后能看到 per-CPU 行） - 按
Shift+P按 CPU 使用率排序，但注意这是“最近采样周期内”的瞬时值，非长期平均 - 若进程
%CPU长期稳定在 200%（双核机器），大概率是多线程程序，不是异常 - 真正可疑的是单线程进程持续 >100%，可能陷入死循环或自旋锁
RES 和 %MEM 对不上？别信默认内存列
RES（Resident Set Size）是进程实际占用的物理内存页大小，但 %MEM 是按 RES / 总物理内存 计算的——它没考虑 cgroups 限制、内存压缩（zswap）、或共享内存页重复计算。更麻烦的是：top 默认不显示 AVG 或 SWAP，而 VIRT 又包含 mmap 的文件映射和 swap-out 部分，完全不能反映真实压力。
- 按
f进入字段管理，启用SWAP和CODE列，辅助判断是否大量换出或加载了大段只读代码 - 关注
RES+SWAP总和是否逼近 cgroup memory limit（如有） - 若
RES很高但free -h显示可用内存充足，可能是内核缓存（Cached）占大头，非应用泄漏
如何让 top 真正“实时”且避免干扰？
top 默认刷新间隔是 3 秒，且会因终端尺寸变化、键盘输入暂停更新——这对抓取短时毛刺（如 500ms 的 CPU 尖峰）完全无效；同时，开启颜色或复杂字段会增加 TTY 渲染开销，反而掩盖真实延迟。
- 启动时加参数：
top -d 0.5 -n 1（0.5 秒刷新，只运行 1 次）配合watch -n 0.5 'top -bn1 | head -20'更可靠 - 禁用颜色：
top -c -C中的-C关闭 ANSI 色彩，减少 SSH 延迟误判 - 避免在 tmux/screen 中嵌套使用 top，子会话的尺寸重绘可能丢帧
- 若需长期记录，用
pidstat -u 1 300 > cpu.log替代，精度更高、无交互干扰
top 里看不到 I/O 等待？那得切到另一套指标
top 的 %CPU 列里，“等待 I/O 完成”的时间（%wa）只显示在顶部 summary 行的 %wa 字段，进程列表里没有任何一列对应 IO-wait。更糟的是：当磁盘卡住，进程状态变成 D（uninterruptible sleep），top 既不标红也不告警，只静静躺在那里。
- 顶部行中
%wa> 20% 且%idle低，说明 I/O 是瓶颈，此时应立刻查iostat -x 1 - 按
Shift+H可切换线程视图，D状态线程会暴露阻塞点（如nvme_wait_cqe） - 想看某进程 IO 速率？
top不行，改用iotop -p $(pgrep -f 'your_process') - 注意：容器环境中的
%wa可能被宿主机层吸收，看到的值比实际低
真正难的不是看懂 top 字段，而是理解它背后没有显示的东西：cgroup 边界、NUMA 节点分布、eBPF 可见的内核路径延迟、以及你 ssh 连接本身带来的采样抖动。盯屏幕不如先跑一遍 perf top -p $(pgrep -f your_app)。
