Linux 内存分析工具 —— heaptrack

Reference:

1. github: heaptrack

heaptrack 是一个堆内存使用分析器，可以分为两个工具：

1. 用于数据收集的 heaptrack
2. 用于可视化显示的 heaptrack_gui。

两者可以独立构建，但版本需要配套。

heaptrack 使用 LD_PRELOAD 跟踪对核心内存分配函数的所有调用，并记录这些调用。此外，还可以获取并记录回溯记录。结合这些可以给出一些有趣的问题的答案，例如：

• 某个应用程序使用了多少堆内存?
• 堆内存被分配到哪里，多长时间分配一次?
• 堆分配请求多少空间?

要评估生成的 heaptrack 数据，使用 heaptrack_print 或 heaptrack_gui。

1. 安装方式

sudo apt-get install heaptrack
sudo apt-get install heaptrack-gui

heaptrack -v # 查看版本号

2. Heaptrack 和 valgrind massif 对比

• valgrind massif 提供了堆分析功能，但存在以下问题：

  1. 运行速度慢：尤其是在多线层应用程序上，valgrind 是序列化代码执行，因此开销很大。而在使用 heaptrack 对多线程应用程序进行内存跟踪时，这些应用程序不会被序列化。序列化意味着将多线程程序转换成单线程程序，从而降低并行性。 heaptrack 允许多线程程序在跟踪过程中保持其并行性，从而不会影响其性能。即使是单线程应用程序，使用 heaptrack 进行内存跟踪时，在时间和内存方面的开销也显著降低。这意味着相比于其他内存跟踪工具，heaptrack 对单线程程序的性能影响更小。(测试下来感觉慢了数十倍，反正 valgrind massif 在我的框架下根本没法用，实在太慢了)
  2. 不容易使用：massif 通常需要寻找各种合适参数以进行使用，--depth、--detailed freq 和 --max 等等，生成的数据也偏粗糙
  3. 结束时才输出：massif 要在调试对象结束时才输出数据，这一步骤会丢失许多有用的信息。最明显的是，将无法找出内存被分配了多少次，或者临时分配被触发的位置。而 heaptrack

• 此外，gperftools 也有类似 heaptrack 的功能，但不能提供 heaptrack 那么多的数据，也没有那么高效。

3. 使用方式

3.1 heaptrack

Usage: /usr/bin/heaptrack [--debug|-d] DEBUGGEE [ARGUMENT]...
or:    /usr/bin/heaptrack [--debug|-d] -p PID
or:    /usr/bin/heaptrack -a FILE

heaptrack 的必选参数：

• DEBUGGEE：应该在启用 heaptrack 分析的情况下运行的应用程序的名称或路径。

或者，attach 到一个正在运行的进程(不建议使用)：

• -p，--pid PID：将被注入 heaptrack 的运行进程的进程号(ID)。这只适用于已经链接到 libdl 的应用程序。
  • 警告：运行时附加 heaptrack 是不稳定的，可能导致应用程序崩溃，特别是在再次分离 heaptrack 之后。

heaptrack 可选参数：

• -d, --debug：在 GDB 和 heaptrack 中运行 debuggee。
• ARGUMENT：参数将逐字传递给被调试程序的参数数目。
• -h, --help：显示帮助信息并退出。
• -v, --version：显示版本信息。

或者，分析记录的 heaptrack 数据文件:

• -a, --analyze file：如果可用，在 heaptrack_gui 中打开 heaptrack 数据文件，否则回退到 heaptrack_print。在 --analyze 之后传递的任何选项都将被传递。

使用命令：

heaptrack ./build/test_pipeline

生成形如 heaptrack.test_pipeline.2683188.zst 的文件。

3.2 heaptrack_gui

使用命令：

heaptrack_gui heaptrack.test_pipeline.2683188.zst
同 heaptrack --analyze “/home/mi/disk2/Project/2.camdrcal/camdrcal/heaptrack.test_pipeline.2683188.zst”

即可打开刚生成文件报告的 gui 界面。