top 默认 %CPU 是采样周期内平均值且多核可超100%，易误判；应按1显示各核负载、用pidstat分项采样、以available而非free评估内存压力。
top 命令看 CPU 占用不准？别信默认的 %CPU 列
Linux 的 top 默认显示的 %CPU 是进程在整个采样周期内的平均占用率，不是瞬时值；多核系统下还可能超过 100%，容易误判“某个进程吃满 CPU”。
实操建议：
- 按
Shift + P确保按 CPU 排序，再按1显示所有 CPU 核心的负载（否则只显示总和） - 关注
ni（nice 值）、pr（优先级）和vsz/rss，比单纯看 %CPU 更能定位是计算密集还是内存压力大 - 如果发现某个进程 %CPU 长期在 200–300，大概率跑在 4 核机器上且占满 2–3 个核，不是单核 200%
用 pidstat 替代 top 查细粒度 CPU/IO 指标
top 是交互式快照，pidstat 才是做性能归因的主力——它能按秒采样、分进程打点、分离 CPU 用户态/内核态、区分磁盘 I/O 类型。
常见错误：直接跑 pidstat 不带参数，结果只输出标题没数据。
实操建议：
- 查每秒 CPU 使用：
pidstat -u 1（-u是用户态 CPU，默认也含内核态） - 查磁盘 IO 等待：
pidstat -d 1，重点看%iowait和rkB/s/wkB/s - 加
-t可看到线程级数据，对 Java 应用排查 GC 线程卡顿很关键
free 输出里的 available 字段到底怎么算出来的
free 命令里 available 列不是 “剩余可用内存”，而是内核估算的、可立即分配给新进程而不触发 OOM 或严重 swap 的内存上限。它比 free 列高得多，但也不等于真实空闲。
为什么重要？因为很多监控脚本还在用 free / total 算“内存使用率”，结果在容器或缓存型服务（如 Redis、Elasticsearch）上严重失真。
实操建议：
- 不要用
free列除以total来告警；优先看available是否持续低于阈值（比如 -
available会受/proc/sys/vm/vfs_cache_pressure影响：值越大，内核越激进回收 dentry/inode 缓存，available就显得越高 - 查真实压力，配合
cat /proc/meminfo | grep -E "^(MemAvailable|SReclaimable|PageTables)"
vmstat 1 输出中 si/so 高 ≠ 一定在 swap
vmstat 1 里 si（swap in）和 so（swap out）为 0，不代表没发生 swap；它们只统计页换入/换出的 KB 数，而 Linux 从 4.19+ 开始默认启用 swap-backed transparent huge pages，大页 swap 不走这套计数器。
更隐蔽的问题是：si/so 高往往伴随 bi/bo（块设备读写）同步飙升，说明磁盘 IO 已成瓶颈，swap 只是表象。
实操建议：
- 先确认是否真用了 swap：
swapon --show和cat /proc/swaps - 查 swap 活跃度：
grep -i "swap" /proc/vmstat（看pgpgin/pgpgout） - 如果
so持续 > 0 且bi很低，可能是 SSD 延迟低掩盖了 swap 开销；这时更要盯pgmajfault（次缺页中断）是否上升
真正难的不是记命令，是理解每个字段背后内核做了什么动作。比如 available 是估算值，%CPU 是均值，si/so 是采样路径之一——脱离上下文直接读数字，十有八九会导错排查方向。
