50 | 案例篇：动态追踪怎么用？（上）

倪朋飞



该思维导图由 AI 生成，仅供参考

你好，我是倪朋飞。
上一节，我以 ksoftirqd CPU 使用率高的问题为例，带你一起学习了内核线程 CPU 使用率高时的分析方法。先简单回顾一下。
当碰到内核线程的资源使用异常时，很多常用的进程级性能工具，并不能直接用到内核线程上。这时，我们就可以使用内核自带的 perf 来观察它们的行为，找出热点函数，进一步定位性能瓶颈。不过，perf 产生的汇总报告并不直观，所以我通常也推荐用火焰图来协助排查。
其实，使用 perf 对系统内核线程进行分析时，内核线程依然还在正常运行中，所以这种方法也被称为动态追踪技术。
动态追踪技术，通过探针机制，来采集内核或者应用程序的运行信息，从而可以不用修改内核和应用程序的代码，就获得丰富的信息，帮你分析、定位想要排查的问题。
以往，在排查和调试性能问题时，我们往往需要先为应用程序设置一系列的断点（比如使用 GDB），然后以手动或者脚本（比如 GDB 的 Python 扩展）的方式，在这些断点处分析应用程序的状态。或者，增加一系列的日志，从日志中寻找线索。
不过，断点往往会中断应用的正常运行；而增加新的日志，往往需要重新编译和部署。这些方法虽然在今天依然广泛使用，但在排查复杂的性能问题时，往往耗时耗力，更会对应用的正常运行造成巨大影响。

公开

同步至部落

取消

完成

0/2000

荧光笔

直线

曲线

笔记

复制

AI

深入了解
翻译
英语
中文简体
中文繁体
法语
德语
日语
韩语
俄语
西班牙语
阿拉伯语
解释
总结

动态追踪技术是一种无需修改代码即可采集内核或应用程序运行信息的方法，有助于分析和定位性能问题。本文详细介绍了动态追踪的原理、事件源和机制，包括静态探针、动态探针和硬件事件。文章提到了 ftrace、perf 和 eBPF 等动态追踪的机制，并通过案例演示了如何使用这些机制来动态追踪内核和应用程序的执行情况。动态追踪技术的出现为排查性能问题提供了完美方案，不需要停止服务或修改代码，且性能损耗较小。读者可以通过本文全面了解动态追踪技术的原理和应用，为进一步深入学习和实践提供了指导。

仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《Linux 性能优化实战》，新⼈⾸单¥68

立即购买

登录后留言

全部留言(32)

最新
精选

我来也
[D50打卡] 课后思考题,我的思考,不一定准确. 我觉得昨天的perf和火焰图,是采样. 而今天的ftrace是实实在在的分析每次一的调用. 虽然都可以看调用堆栈和耗时比例. 但是ftrace应该是非常准确,而perf只是一个采样,比如采样频率1%. 我觉得找大方向时,使用perf和火焰图, 找具体问题时,用ftrace.毕竟ftrace需要知道调用的系统函数. ftrace需要追踪的信息可以来源于perf的分析结果.
作者回复: 嗯嗯，非常准确。函数跟踪需要实现知道函数名，而perf/火焰图就可以找出热点函数。
2019-03-20
2
46
lizh
早些时间整理过的一篇文章，和这个主题很match，分享在这里^_^。https://leezhenghui.github.io/linux/2019/03/05/exploring-usdt-on-linux.html
作者回复: 👍谢谢分享
2019-03-20

30
Huayra
将性能优化大师Brendan Gregg的blog阅读一遍，就能够更深刻地理解这一章。据说，OpenResty的作者张亦春也阅读过Brendan Gregg的所有博客，他现在更进一步地开发了一个将高级编程语言编译成动态追踪脚本的工具
作者回复: 👍
2019-03-20
2
20
佳
在和同事讨论nodejs使用从thrift转化到grpc时候会性能下降问题就用老师介绍 strace -T -ttt -p pid 找到根源。 grpc -node版本发送分两次writev系统调用，第一次发送 grpc路径，第二次发送参数。比thrift协议一次效率一些。再发现node并发次数多，回调算时间往往是多个调用所花的时间。这些效率都用strace看到，在前面时间
作者回复: 👍谢谢分享
2019-03-23

6
Linuxer
老师，碰到一个问题怎么选择tracepoint和tracefunction呢？然后怎么结合输出分析问题呢？
作者回复: 先要用其他工具定位出大概的位置，比如用perf或者bcc等等。有了函数之后，再回来跟踪函数的内部。
2019-03-20

3
z.l
请教下java里常用的btrace和今天讲的几个工具是什么关系啊
作者回复: 今天介绍的工具都是系统级工具，可以用在任何应用；而btrace是应用级的，只能用在Java应用上。
2019-04-21

2
青石
#echo function_graph > current_trace -bash: current_trace: Permission denied 报上面错误的同学，可以尝试下面的命令，环境是CentOS 7.6 $ echo function_graph > current_tracer $ echo funcgraph-proc > trace_options
作者回复: 谢谢分享
2019-03-22

2
金波
请教老师个问题，遇到一个问题是，嵌入式linux系统上，几秒钟之内某个进城突然导致OOM。请问有没有什么好的方法调查或者捕捉谁短时间占用大量内存吗？脚本几秒检测maps试过，捕捉不到。内存钩子一是不线程安全，再就是应该用了tcmalloc，应该也不行。 valgrind太重量级，大程序跑不动。多谢
作者回复: 动态追踪（比如bcc或者systemtap）应该是最好用的方法了。如果发送了OOM，从系统日志里面也可以找到线索
2019-03-25

1
xfan
我的机器一运行 echo function_graph > current_trace或trace-cmd的命令就卡死，tty1也输入不了，我现在是ubuntu18.04 双处理器 1G内存
作者回复: 这个问题我也是第一次见到，检查下系统日志里面有没有错误？
2019-03-22

1
Chn.K
老师，请教个问题，对于踩内存导致的coredump问题（从core文件大致能看出来内存已经乱了，但是看不出来是哪里把内存搞乱了），有没有好的定位方法？
作者回复: coredump提供了问题的现场，从coredump分析（比如使用GDB）应该就是最好的方法了，
2019-03-20

1

收起评论