使用火焰图诊断内存泄漏
内容提要
GreptimeDB采用Jemalloc作为默认的内存分配器，提高了性能和内存分析能力。本文介绍了使用Jemalloc解决内存问题的技巧，包括在GreptimeDB中启用堆分析、使用jeprof和flamegraph.pl等工具可视化内存使用情况、解释火焰图以及通过分配差异捕捉内存泄漏。文章还建议使用glimi-rs/addr2line加快火焰图生成速度。
延伸解读
启用堆分析的两个关键步骤
在 GreptimeDB 中启用 Jemalloc 堆分析需要两个步骤：编译时开启 mem-prof 特性，运行时设置 MALLOC_CONF=prof:true 环境变量。两者缺一不可，否则通过 curl 访问 /v1/prof/mem 会返回错误提示。这种设计将功能开关与运行时配置分离，便于在生产环境中按需启用，避免不必要的性能开销。
火焰图宽度与平台的含义
火焰图中每个单元格的宽度代表该函数及其子函数分配的内存总量，越宽表示分配越多。如果某个函数自身分配了大量内存但子函数调用很少，其顶部会呈现较宽的“平台”形状，这提示该函数内部可能存在大量分配操作，是排查内存问题的重点区域。颜色仅为随机暖色，不承载额外信息。
用基线差异定位缓慢泄漏
内存泄漏通常表现为内存缓慢增长，直接观察火焰图难以发现。有效方法是在内存正常时采集基线数据，待内存增长后再次采集，并使用 jeprof 的 --base 参数指定基线生成差异火焰图。这样图中只显示两次采集之间的内存分配差异，能更清晰地暴露导致内存增长的具体函数调用。
加速火焰图生成的实用技巧
生成火焰图时，将函数地址转换为文件名和行号是最耗时的步骤。默认使用 GNU Binutils 的 addr2line 工具，但可以替换为 glimi-rs/addr2line 来获得至少两倍的生成速度提升。替换方法简单：编译后备份原工具并覆盖即可。对于需要频繁分析内存的场景，这一优化能显著减少等待时间。
Q&A
GreptimeDB 为什么选择 Jemalloc 作为默认内存分配器？
GreptimeDB 从去年六月（greptimedb#1733）开始采用 Jemalloc 作为默认内存分配器，因为它不仅能提升性能、减少内存碎片，还提供了便捷的内存分析能力。
如何在 GreptimeDB 中启用堆内存分析功能？
需要在编译 GreptimeDB 时开启 mem-prof 特性（cargo build --release -F mem-prof），并在启动时设置环境变量 MALLOC_CONF=prof:true。
怎样确认 GreptimeDB 的堆分析已经成功开启？
可以通过 curl 命令访问 <greptimedb_ip>:4000/v1/prof/mem，如果返回类似 'heap_v2/524288 t*: 125: 136218 ...' 的数据，说明堆分析已开启；如果返回 {"error":"Memory profiling is not enabled"}，则表明 MALLOC_CONF=prof:true 未正确设置。
如何生成 GreptimeDB 内存分配的火焰图？
首先通过 curl <greptimedb_ip>:4000/v1/prof/mem > mem.hprof 获取内存分配数据，然后使用 jeprof <path_to_greptime_binary> ./mem.hprof --collapse | flamegraph.pl > mem-prof.svg 生成火焰图文件 mem-prof.svg。
火焰图中的宽度和颜色分别代表什么？
火焰图中每个单元格的宽度表示该函数及其子函数分配的内存总量，宽度越大表示分配内存越多；颜色是随机的暖色调，没有特定含义。
如何加速火焰图的生成过程？
可以使用 glimi-rs/addr2line 替换 GNU Binutils 的 addr2line 工具，从而获得至少 2 倍的生成速度提升。具体步骤包括克隆仓库、编译并替换系统默认的 addr2line。
怎样通过内存分配差异来捕捉内存泄漏？
在内存增长过程中，先在初始时间点采集内存数据作为基线（curl -s <greptimedb_ip>:4000/v1/prof/mem > base.hprof），待内存明显增长后再采集一次（leak.hprof），然后使用 jeprof --base ./base.hprof ./leak.hprof --collapse | flamegraph.pl > leak.svg 生成差异火焰图，从而清晰看出哪些函数调用导致了内存增长。
