还在 top 和 ps？系统卡顿的真正元凶，99%的人忽略了这招！（附实战）

👀 为什么你总感觉 Linux 跑不动了？

“CPU 飙高”、“系统卡顿”、“接口延迟波动”…… 是不是你也经历过这些情况，然后打开 top 一看，好像也没啥不对？

别急！这就是你要看的文章。今天我们从系统内核的视角出发，教你用一套现代工程师必备的排查路径 + 新利器——eBPF，真正摸清 Linux 卡顿背后的真相。

🎯 为什么传统工具越来越“看不出问题”？

过去我们排查 Linux 性能问题，可能会习惯使用这些工具：

• top、htop：看 CPU、负载
• ps -ef：看进程树
• iotop：看磁盘 IO
• netstat：看连接状态

这些命令确实有用，但它们局限于应用层或统计信息。当问题藏在内核态、内存分配器、上下文切换频率中时，它们就开始“失灵”了。

💡新一代“显微镜”：eBPF 初识

eBPF（extended Berkeley Packet Filter）是 Linux 4.x 后引入的技术，它的厉害之处在于：

能够在不修改内核源码的前提下，在内核空间运行沙盒程序，实时采集各种底层指标。

通俗讲：你可以给内核“打补丁”，让它告诉你真实的瓶颈！

🔍 真实案例：接口变慢，原来是内核调度抢锁了！

我们某一次线上排查，一个接口平均耗时从 30ms 飙升到 300ms+，普通监控没发现明显 CPU 异常。

步骤1：观察 syscall（系统调用）

我们用 bcc 工具集 中的 execsnoop、opensnoop、biolatency 工具，快速发现：

sudo biolatency

输出中显示有 某块磁盘延迟瞬时飙升到 300ms+，严重阻塞了请求处理线程。

步骤2：追查进程调度瓶颈

再用：

sudo runqlat

步骤3：发现锁竞争严重

最后使用：

sudo offcputime -df

这个命令可以抓取线程在非 CPU 时间的堆栈，也就是“为什么不执行”的原因。

输出显示大量线程卡在：

mutex_lock
futex_wait

最终排查出是某个 Go 服务模块加锁过猛，导致线程堆积——应用锁问题被内核暴露。

🔧 实战工具推荐

用类似脚本语言快速观察系统行为

🔚 总结：新时代的 Linux 性能排查三板斧

1. 先用传统工具“扫一遍”，top/ps/dstat 等了解是否有明显瓶颈；
2. 借助 eBPF 精准定位问题源头，如 syscall、调度、锁、IO 等；
3. 建立问题模型 + 指标体系，定期扫描慢调用、高频切换点。

一句话总结

Linux 不卡，是你不会看。eBPF 不会用，是你还没开始进化。

如果你对 Linux 调优、eBPF 实战、系统级 DevOps 感兴趣，点赞 + 收藏，下一篇教你用 bpftrace 写出自己的性能分析脚本！

END