在真实生产环境中性能问题从来不是“某一个工具”能解决的。CPU飙高、IO抖动、网络延迟、系统Load异常,本质上都涉及从应用 → 内核 → 硬件的全链路观测能力。
Linux性能观测本质是回答三类问题:
(1)谁在慢?(进程/线程/内核路径)
(2)慢在哪里?(CPU/IO/内存/ 网络)
(3)为什么慢?(调度、锁、缓存、硬件瓶颈)
很多工程师的问题在于只会top/iostat/vmstat,至于perf/eBPF工具“知道名字,不知道该什么时候用”,出现性能问题,只能“经验猜测”,无法证据驱动分析,核心原因其实是没有把Linux性能问题映射到操作系统分层架构上。这里整理了一个不同层级的工具参照表,在实际工作中可以进行实践:
(1)应用/系统调用层(“程序在干什么”):strace/ltrace/lsof/opensnoop,比如应用“看起来很忙但CPU不高”的场景
(2)内核文件系统/IO路径(“IO为什么慢”):iostat/blktrace/biosnoop/ext4slower,比如ES/MySQL/日志系统IO抖动的场景
(3)网络协议栈(“包去哪儿了”):ss/tcpdump/tcpretrans/nicstat,比如RT高但服务端CPU正常的场景
(4)调度/CPU/内存(“谁在抢资源”):perf/offcputime/runqlen/vmstat/numastat
ps:如何线上OS内核版本很高(比如5.10+)那么我们优先使用eBPF生态工具进行性能排查