記一次Rust內(nèi)存泄漏排查之旅

在某次持續(xù)壓測(cè)過(guò)程中，我們發(fā)現(xiàn) GreptimeDB 的 Frontend 節(jié)點(diǎn)內(nèi)存即使在請(qǐng)求量平穩(wěn)的階段也在持續(xù)上漲，直至被 OOM kill。我們判斷 Frontend 應(yīng)該是有內(nèi)存泄漏了，于是開(kāi)啟了排查內(nèi)存泄漏之旅。

Heap Profiling

大型項(xiàng)目幾乎不可能只通過(guò)看代碼就能找到內(nèi)存泄漏的地方。所以我們首先要對(duì)程序的內(nèi)存用量做統(tǒng)計(jì)分析。幸運(yùn)的是，GreptimeDB 使用的 jemalloc 自帶 heap profiling[1]，我們也支持了導(dǎo)出 jemalloc 的 profile dump 文件[2]。于是我們?cè)?GreptimeDB 的 Frontend 節(jié)點(diǎn)內(nèi)存達(dá)到 300MB 和 800MB 時(shí)，分別 dump 出了其內(nèi)存 profile 文件，再用 jemalloc 自帶的jeprof分析兩者內(nèi)存差異（--base參數(shù)），最后用火焰圖顯示出來(lái)：

顯然圖片中間那一大長(zhǎng)塊就是不斷增長(zhǎng)的 500MB 內(nèi)存占用了。仔細(xì)觀察，居然有 thread 相關(guān)的 stack trace。難道是創(chuàng)建了太多線(xiàn)程？簡(jiǎn)單用ps -T -p命令看了幾次 Frontend 節(jié)點(diǎn)的進(jìn)程，線(xiàn)程數(shù)穩(wěn)定在 84 個(gè)，而且都是預(yù)知的會(huì)創(chuàng)建的線(xiàn)程。所以“線(xiàn)程太多”這個(gè)原因可以排除。

再繼續(xù)往下看，我們發(fā)現(xiàn)了很多 Tokio runtime 相關(guān)的 stack trace，而 Tokio 的 task 泄漏也是常見(jiàn)的一種內(nèi)存泄漏。這個(gè)時(shí)候我們就要祭出另一個(gè)神器：Tokio-console[3]。

Tokio Console

Tokio Console 是 Tokio 官方的診斷工具，輸出結(jié)果如下：

我們看到居然有 5559 個(gè)正在運(yùn)行的 task，且絕大多數(shù)都是 Idle 狀態(tài)！于是我們可以確定，內(nèi)存泄漏發(fā)生在 Tokio 的 task 上?，F(xiàn)在問(wèn)題就變成了：GreptimeDB 的代碼里，哪里 spawn 了那么多的無(wú)法結(jié)束的 Tokio task？

從上圖的 "Location" 列我們可以看到 task 被 spawn 的地方[4]：

implRuntime{
///Spawn a future and execute it in this thread pool
///
///Similar to Tokio::spawn()
pubfnspawn(&self,future:F)->JoinHandle
where
F:Future+Send+'static,
F:Send+'static,
{
self.handle.spawn(future)
}
}

接下來(lái)的任務(wù)是找到 GreptimeDB 里所有調(diào)用這個(gè)方法的代碼。

..Default::default()

經(jīng)過(guò)一番看代碼的仔細(xì)排查，我們終于定位到了 Tokio task 泄漏的地方，并在 PR #1512[5]中修復(fù)了這個(gè)泄漏。簡(jiǎn)單地說(shuō)，就是我們?cè)?strong>某個(gè)會(huì)被經(jīng)常創(chuàng)建的 struct 的構(gòu)造方法中，spawn 了一個(gè)可以在后臺(tái)持續(xù)運(yùn)行的 Tokio task，卻未能及時(shí)回收它。對(duì)于資源管理來(lái)說(shuō)，在構(gòu)造方法中創(chuàng)建 task 本身并不是問(wèn)題，只要在Drop中能夠順利終止這個(gè) task 即可。而我們的內(nèi)存泄漏就壞在忽視了這個(gè)約定。

這個(gè)構(gòu)造方法同時(shí)在該 struct 的Default::default()方法當(dāng)中被調(diào)用了，更增加了我們找到根因的難度。

Rust 有一個(gè)很方便的，可以用另一個(gè) struct 來(lái)構(gòu)造自己 struct 的方法，即 "Struct Update Syntax"[6]。如果 struct 實(shí)現(xiàn)了Default，我們可以簡(jiǎn)單地在 struct 的 field 構(gòu)造中使用..Default::default()。

如果Default::default()內(nèi)部有 “side effect”（比如我們本次內(nèi)存泄漏的原因——?jiǎng)?chuàng)建了一個(gè)后臺(tái)運(yùn)行的 Tokio task），一定要特別注意：struct 構(gòu)造完成后，Default創(chuàng)建出來(lái)的臨時(shí) struct 就被丟棄了，一定要做好資源回收。

例如下面這個(gè)小例子：Rust Playground[7]

structA{
i:i32,
}

implDefaultforA{
fndefault()->Self{
println!("called A::default()");
A{i:42}
}
}

#[derive(Default)]
structB{
a:A,
i:i32,
}

implB{
fnnew(a:A)->Self{
B{
a,
//A::default()is called in B::default(),even though"a"is provided here.
..Default::default()
}
}
}

fnmain(){
leta=A{i:1};
letb=B::new(a);
println!("{}",b.a.i);
}

struct A 的default方法是會(huì)被調(diào)用的，打印出called A::default()。

總結(jié)

?排查 Rust 程序的內(nèi)存泄漏，我們可以用 jemalloc 的 heap profiling 導(dǎo)出 dump 文件；再生成火焰圖可直觀展現(xiàn)內(nèi)存使用情況。

? Tokio-console 可以方便地顯示出 Tokio runtime 的 task 運(yùn)行情況；要特別注意不斷增長(zhǎng)的 idle tasks。

?盡量不要在常用 struct 的構(gòu)造方法中留下有副作用的代碼。

?Default只應(yīng)該用于值類(lèi)型 struct。

審核編輯：湯梓紅