使用 jemalloc profile memory
对于长时间运行的服务端程序,内存的使用一直是一个非常重要的监控指标,当内存的使用量一直在上升的时候,我们就需要警觉起来,因为很有可能整个系统出现了内存泄露。那么剩下的问题就比较简单了,如何动态的获知哪里有内存泄露呢?
对 Go 的程序来说,我们可以使用语言内置的 pprof 工具非常方便的对内存进行 profile,我们只需要在程序里面 import _ "net/http/pprof"
,这样启动的 HTTP server 服务器就能够被直接 profile 了。
但对 Rust,情况就没那么简单了。因为语言并没有内置这个功能,所以我们得想其他办法来解决。Rust 默认使用的是 jemalloc 这个内存分配器,jemalloc 提供了非常方便的 profile 功能。所以我们自然将目光放在了如何用 jemalloc 来 profile memory 以及如何与 Rust 整合上面了。
要打开 jemalloc 的 profile 功能,在编译的时候我们需要显示的带上 --enable-prof
选项,通常在 Linux 下面我们会安装 libunwind
库,这样 prof 默认就会使用 libunwind
了。另外,为了不跟系统的 malloc 这些函数有命名冲突,这里显示的给 jemalloc 加上了前缀,使用 --with-jemalloc-prefix="je_"
,这样我们外面就会使用 je_malloc
这种的函数名字了。
我们用官网非常简单的例子来说明内存泄露问题,如下:
void do_something(size_t i)
{
// Leak some memory.
je_malloc(i * 100);
}
上面的函数有一个典型的内存泄漏,我们调用 1000 次:
for (i = 0; i < 1000; i++) {
do_something(i);
}
剩下的就是如何来定位内存问题了。
Mem Statistics
首先我们来看看 jemalloc 自己提供的统计信息,我们可以直接使用 je_malloc_stats_print(NULL, NULL, NULL)
来将 memory 的统计输出到 stderr 上面,但这个函数输出的东西比较多,并不利于实时的查看。多数时候,我们都是使用 je_mallctl
函数,得到一些关键的统计数据,然后发送给 Prometheus 来展示,这样我们就能够在 Prometheus 里面观察到整个 jemalloc 内存变化的曲线,如果持续上升,就需要报警了。
uint64_t epoch = 1;
size_t sz = sizeof(epoch);
je_mallctl("epoch", &epoch, &sz, &epoch, sz);
size_t allocated, active, mapped;
sz = sizeof(size_t);
je_mallctl("stats.allocated", &allocated, &sz, NULL, 0);
je_mallctl("stats.active", &active, &sz, NULL, 0);
je_mallctl("stats.mapped", &mapped, &sz, NULL, 0);
printf("allocated/active/mapped: %zu/%zu/%zu\n", allocated, active, mapped);
上面我们在每次 do_something
后面得到 allocated,active 以及 mapped 这些指标,然后输出:
allocated/active/mapped: 54919648/58540032/64831488
allocated/active/mapped: 55034336/58658816/64950272
allocated/active/mapped: 55149024/58777600/65069056
allocated/active/mapped: 55263712/58896384/65187840
上面需要注意,我们需要用 epoch 来让统计的 cache 更新。
Leak Check
通过统计,我们能看到整个内存的变化曲线,但到底哪里有内存问题呢?我们可以在程序结束的时候显示的输出内存泄露。仍然使用上面的程序,我们使用 JE_MALLOC_CONF="prof_leak:true,lg_prof_sample:0,prof_final:true" ./leak
来执行,当程序退出之后,会生成一个 prof heap 的文件,我们用 jeprof 工具就可以知道内存泄露了。
jeprof leak jeprof.9001.0.f.heap
Using local file leak.
Using local file jeprof.9001.0.f.heap.
Welcome to jeprof! For help, type 'help'.
(jeprof) top
Total: 52.1 MB
52.1 100.0% 100.0% 52.1 100.0% je_prof_backtrace
0.0 0.0% 100.0% 52.1 100.0% __libc_start_main
0.0 0.0% 100.0% 52.1 100.0% _start
0.0 0.0% 100.0% 52.1 100.0% do_something
0.0 0.0% 100.0% 52.1 100.0% imalloc (inline)
0.0 0.0% 100.0% 52.1 100.0% imalloc_body (inline)
0.0 0.0% 100.0% 52.1 100.0% je_malloc
0.0 0.0% 100.0% 52.1 100.0% je_prof_alloc_prep (inline)
0.0 0.0% 100.0% 52.1 100.0% main
Heap Profiling
使用上面的方式,我们只能在程序结束的时候输出内存泄露,实际并不适用于长时间运行的程序,幸运的时候,我们可以通过 jemalloc 的一些参数以及 mallctl
函数来显示的对内存进行 profile。在运行程序之前,我们需要设置 export JE_MALLOC_CONF="prof:true,prof_prefix:jeprof.out"
,它用来告诉 jemalloc 显示的打开 prof,同时自动的生成 profile 文件名。
在代码里面,我们可以使用 mallctl("prof.dump", NULL, NULL, NULL, 0);
来对当前执行的程序生成一个 mem dump,然后过一段时间之后,用相同的方法再次生成一个,在用 jeprof 工具对比两次的 dump,就大概能知道是否有内存问题了。
具体到上面的例子,我们在程序的开始和结束都使用 mallctl
dump 一次 memory,然后对两次生成的 profile 文件进行对比:
jeprof --base=jeprof.out.19792.0.m0.heap profile jeprof.out.19792.1.m1.heap
Using local file profile.
Using local file jeprof.out.19792.1.m1.heap.
Welcome to jeprof! For help, type 'help'.
(jeprof) top
Total: 53.1 MB
53.1 100.0% 100.0% 53.1 100.0% je_prof_backtrace
0.0 0.0% 100.0% 53.1 100.0% __libc_start_main
0.0 0.0% 100.0% 53.1 100.0% _start
0.0 0.0% 100.0% 53.1 100.0% do_something
0.0 0.0% 100.0% 53.1 100.0% imalloc (inline)
0.0 0.0% 100.0% 53.1 100.0% imalloc_body (inline)
0.0 0.0% 100.0% 53.1 100.0% je_malloc
0.0 0.0% 100.0% 53.1 100.0% je_prof_alloc_prep (inline)
0.0 0.0% 100.0% 53.1 100.0% main
Rust Customized Allocator
上面说完了在 C 里面使用 jemalloc 来看内存问题,那么对于 Rust 语言来说,我们怎么处理呢?Rust 默认使用的就是 jemalloc,但发布的版本里面 jemalloc 并没有带上 profile 的功能,所以需要重新编译 Rust,对于我们来说,因为要实时的跟进 Rust 的版本,这并不是一个好办法。
幸运的是,Rust 提供了 custom allocator 的功能,也就是能使用自定义的 allocator,这样对我们来说就简单很多了,使用一个打开了 profile 功能的 jemalloc 用作自定义的 allocator,这样就能通过 mallctl
来 profile memory 了。更幸运的是,Rust 的一个开发者已经提供了相关的 allocator,我们可以直接使用。
我们可以构造一个非常简单的 case,使用 mem::forget
:
fn do_something()
{
let mut bad_vec = Vec::new();
for _ in 0..1024 {
bad_vec.push('0');
}
mem::forget(bad_vec);
}
在这个函数前后,我们都使用 mallctl
,如下:
let epoch_name = "prof.dump";
let epoch_c_name = CString::new(epoch_name).unwrap();
mallctl(epoch_c_name.as_ptr(), null_mut(), null_mut(), null_mut(), 0);
执行之后,就会生成两个 profile 文件,使用 jeprof 之后,得到:
(jeprof) top
Total: 0.5 MB
0.5 100.0% 100.0% 0.5 100.0% jemallocator::__rust_reallocate
0.0 0.0% 100.0% 0.5 100.0% __libc_start_main
0.0 0.0% 100.0% 0.5 100.0% _start
0.0 0.0% 100.0% 0.5 100.0% alloc::heap::reallocate::h1264a9399460da6c
0.0 0.0% 100.0% 0.5 100.0% alloc::raw_vec::{{impl}}::double
0.0 0.0% 100.0% 0.5 100.0% collections::vec::{{impl}}::push
0.0 0.0% 100.0% 0.5 100.0% core::ops::FnOnce::call_once (inline)
0.0 0.0% 100.0% 0.5 100.0% main
0.0 0.0% 100.0% 0.5 100.0% my_allocator::do_something::h4ffe20b1f68a3f80
0.0 0.0% 100.0% 0.5 100.0% my_allocator::main::hffe46171bdd5ea12
小结
内存问题一直是长时间运行程序需要处理的一个棘手问题,虽然 Rust 相比 C 以及 CPP,在内存处理上面有了很大的改善,但我们仍然可能会有引用泄露等问题出现,这些问题很难通过直接浏览代码,看 log 和 metrics 来看出来的,而 profile 恰恰能很好的解决,所以这也是我们一直想在 TiKV 上面加入 profile memory 的原因。
需要注意,加入 profile 之后,会影响系统的性能,所以通常,我们都会采用 sample 的方式或者动态的打开或者关闭 profile 功能。譬如,假设我们要 profile memory,就使用 mallctl
将 prof.active
打开,一段时间,在使用 mallctl
dump 出 memory,然后在关闭 profile。
另外,除了 jemalloc,其实 tcmalloc 也照样能支持 profile memory,只是因为 Rust 默认使用的是 jemalloc,我们最终我们还是决定基于 jemalloc 来使用。