性能问题应先看CPU、内存、IO、网络四类关键指标，再依现象反推瓶颈类型：如%wa>5%指向磁盘，available≈0且swap启用说明内存瓶颈，r值持续>CPU核心数需结合us/sy/wa判断，%util>80%且await远高于svctm表明磁盘队列积压，rxdrop/txerr上升提示网卡驱动或缓冲区问题；top仅显示进程级CPU，须用top -H查线程、perf top -k查内核态、/proc/interrupts查中断源；需用sar、pidstat等采集时间序列数据，避免快照误判；工具使用应以证伪当前假设为前提，避免过度分析。
性能问题到底出在哪儿？先看这四个关键指标
别一上来就跑 top 狂按 P 排序，真正的系统性思路是从现象反推瓶颈类型。CPU 高、内存吃紧、IO 等待长、网络延迟大——这四类表现对应完全不同的排查路径。比如 %wa 在 vmstat 里持续 >5%，基本可以排除 CPU 密集型问题，直接切到磁盘子系统；而 free -m 显示 available 接近 0 且 swap 开始使用，说明内存已成瓶颈，此时再盯 CPU 使用率就是干扰项。
-
r值（运行队列长度）长期 > CPU 核心数 → CPU 或 IO 瓶颈的强信号，但需结合us/sy/wa判断是算力不足还是卡在等待 -
iostat -x 1中%util>80% 且await显著高于svctm→ 磁盘队列积压，不是硬件慢，是请求太多或单次太大 -
sar -n DEV 1发现某网卡rxdrop或txerr持续上升 → 不是带宽不够，很可能是驱动、MTU 或网卡缓冲区溢出
为什么 top 找不到真凶？线程级和内核态必须深挖
top 只显示进程级 CPU 占用，但 java 应用里一个 pid 下可能有上百线程，真正烧 CPU 的往往只是其中 1–2 个；同样，us（用户态）占比低不等于 CPU 安全——如果 sy（内核态）飙高，大概率是频繁系统调用、锁竞争或中断风暴。这时候光看 top 就会漏掉根因。
- 查高负载线程：用
top -p→ 按H切换线程视图 → 记下高 CPU 的TID→printf "%xn"转十六进制 → 在jstack输出里搜tid=0x... - 查内核态热点：用
perf top -p看用户态函数；加-k参数（如perf top -k /lib/modules/$(uname -r)/build/vmlinux）才能看到内核函数耗时 - 查中断来源：
cat /proc/interrupts | sort -k 3 -nr | head -10快速定位高频中断设备，再结合lspci和驱动日志判断是否异常
数据不能只看“此刻”，要建立时间维度证据链
单次 vmstat 1 5 只能抓快照，但性能问题是动态演化的。比如内存泄漏不会让 free 瞬间归零，而是表现为 cached 缓慢上涨 + pgmajfault 持续增加；又比如 IO 瓶颈常伴随周期性 b（阻塞进程数）尖峰，单次采样很容易错过。没有时间序列，所有“看起来合理”的结论都可能是巧合。
- 用
sar -u 1 3600（每秒一次，持续 1 小时）捕获 CPU 波动规律，比反复手动top有效十倍 -
pidstat -d 1比iotop更适合长期记录，输出可直接导入 excel 做 IOPS 与响应时间相关性分析 - 不要依赖
df看磁盘空间——它不反映 inode 耗尽；用df -i和find /path -xdev -type f | wc -l双验证
剪枝比构造更难：如何避免陷入“工具依赖症”
手里有 perf、strace、blktrace 就想全用一遍？这是新手最大误区。决策树的价值不在“我能测什么”，而在“我该停在哪”。比如 iostat 已确认磁盘无压力，还去跑 blktrace 分析 IO 路径，纯属浪费时间；又比如 vmstat 显示 r 值始终为 0，却坚持用 perf record -e cycles 做 CPU 火焰图，本质是用高成本手段验证一个已知事实。
- 每用一个工具前，先问：它能证伪我当前的假设吗？如果答案是否定的，跳过
-
strace -p统计系统调用频次，比盲目-c strace -p抓日志高效得多；发现epoll_wait占比超 90%，说明是事件循环阻塞，不用再往下追文件读写 - Java 应用优先用
jstat -gc看 GC 频率和停顿，而不是一上来就jmapdump 全堆——后者可能拖垮生产服务
系统性思路的本质，是把“不知道从哪下手”的焦虑，转化成“下一步该验证哪个假设”的确定动作。最常被忽略的，其实是停止时机：当三个独立工具指向同一个子系统，且指标变化趋势一致，就该收手做优化，而不是继续深挖“为什么这个内核函数会多执行 0.3%”。