基于ebpf的性能工具應(yīng)用
在實際的軟件開發(fā)過程中，內(nèi)存問題常常是耗費大量時間進行分析的挑戰(zhàn)之一。為了更有效地定位和解決與內(nèi)存相關(guān)的難題，一系列輔助工具應(yīng)運而生，其中備受贊譽的Valgrind工具便是其中之一。事實上，筆者本人曾利用Valgrind工具成功地發(fā)現(xiàn)并解決了一個隱藏在軟件中的bug，這充分體現(xiàn)了工具在開發(fā)過程中的重要性。
然而，同樣強大的bpftrace工具同樣具備簡潔而直觀的特點，能夠協(xié)助我們高效地追蹤內(nèi)存泄漏問題。在這方面，bpftrace提供了一種更加精細(xì)的、實時的分析方式，幫助開發(fā)人員準(zhǔn)確地定位代碼中可能存在的內(nèi)存泄漏情況。
構(gòu)建樣例
我們編寫一個程序--mem_check.c，代碼中包含正確的申請內(nèi)存和釋放內(nèi)存的邏輯，同時包含存在內(nèi)存泄露的代碼代碼。。
#include
int main(){
char *p1 = NULL;
char *p2 = NULL;
for(int i = 0; i < 5; i++)
{
p1 = malloc(16);
}
for(int i = 0; i < 5; i++)
{
p2 = malloc(32);
free(p2);
}
getchar();
return 0;
}
上面的代碼非常簡單，我們申請了5次16個字節(jié)的內(nèi)存，沒有釋放，存在內(nèi)存泄露。申請5次32個字節(jié)的內(nèi)存，有釋放，沒存在內(nèi)存泄露。那么我們?nèi)绾瓮ㄟ^bpftrace定位呢？
我們通過bpftrace對mem_check.c進行動態(tài)的統(tǒng)計內(nèi)存的申請和釋放，定位內(nèi)存泄露的問題。我們需要對關(guān)鍵的兩個接口進行probe--malloc和free，這兩個接口的實現(xiàn)在libc中。
編譯mem_check.c文件，生成可執(zhí)行文件：
探測mem_ckeck可執(zhí)行文件
bpftrace可以對內(nèi)核態(tài)進行探測也可以對用戶態(tài)進行探測，其中探針如下：
- 內(nèi)核態(tài)探針：kprobe/kretprobe
- 用戶態(tài)探針：uprobe/uretprobe
mem_check.c是一個應(yīng)用程序，顯然我們需要使用用戶態(tài)探針：uprobe/uretprobe
通過uprobe探測mem_check.c中的malloc函數(shù)，我們單行指令驗證，參數(shù)格式是 uprobe:可執(zhí)行文件:函數(shù)名：
理論是沒有沒有問題，但實際發(fā)生錯誤：No probes to attach。原因：可執(zhí)行文件mem_check中找不到符號：malloc，我們可以通過nm命令確定一下：
我們發(fā)現(xiàn)malloc是一個鏈接自GLIBC_2.2.5的符號，并不是mem_ckeck自身的符號，所以我們探測的符號修改libc庫中malloc符號，系統(tǒng)中可能存在多個c庫，我們需要找到mem_ckeck程序使用的C庫，通過ldd命令查看：
mem_check可執(zhí)行文件使用的C庫為：/lib/x86_64-linux-gnu/libc.so.6，我們將可以執(zhí)行文件替換為/lib/x86_64-linux-gnu/libc.so.6。再次執(zhí)行，會出現(xiàn)大量內(nèi)容，顯然是其他進程調(diào)用了malloc引起的，而我們的mem_ckeck還沒有運行，顯然還沒有探測我們的可執(zhí)行程序。
我們需要進行過濾，增加filter只保留我們關(guān)心的應(yīng)用程序的調(diào)用探測。bpftrace提供了系統(tǒng)變量comm表示可執(zhí)行文件名 (進程名)，只需要在上述指令中增加 filter，只處理comm=="mem_check"的malloc調(diào)用事件。左邊終端執(zhí)行探測，右邊終端執(zhí)行可執(zhí)行文件。每調(diào)用一次malloc函數(shù)，就能探測到一次：
使用bpftrace腳本進一步探測
將上面的單行命令變?yōu)閎pftrace腳本--bpf_test.bt
printf("start proben");
}
uprobe:/lib/x86_64-linux-gnu/libc.so.6:malloc /comm == "mem_check"/{
printf("malloc calln");
}
END {
printf("end proben");
}
探測mem_check中malloc的內(nèi)存空間大小。
malloc的原型：
bpftrace的uprobe和kprobe可以通過內(nèi)置變量arg0、arg1 ··· ··· 訪問函數(shù)參數(shù)，對bpf_test.bt修改就可以打印malloc申請內(nèi)存的大?。?/p>
printf("start proben");
}
uprobe:/lib/x86_64-linux-gnu/libc.so.6:malloc /comm == "mem_check"/{
printf("malloc size: %dn", arg0);
}
END {
printf("end proben");
}
如下圖可以看到mem_check中申請內(nèi)存的情況，最后一個malloc size 1024是mem_check自動創(chuàng)建輸出緩沖區(qū)申請的內(nèi)存，不用理會。
探測mem_check中malloc的返回值
malloc的返回值是地址，需借助uretprobe進行探測，函數(shù)返回值可通過內(nèi)置變量retval訪問。uretprobe的filter與malloc參數(shù)探測時類似，腳本修改為：
printf("start proben");
}
uprobe:/lib/x86_64-linux-gnu/libc.so.6:malloc /comm == "mem_check"/{
printf("malloc size: %dn", arg0);
}
uretprobe:/lib/x86_64-linux-gnu/libc.so.6:malloc /comm == "mem_check"/{
printf("addr = %pn", retval);
}
END {
printf("end proben");
}
運行結(jié)果：
探測mem_check中free
我們已經(jīng)探測到mem_check的malloc的內(nèi)存大小，內(nèi)存的地址，我們通過探測free，然后匹配malloc和free的情況就可以查找內(nèi)存的泄漏點。腳本修改為：
printf("start proben");
}
uprobe:/lib/x86_64-linux-gnu/libc.so.6:malloc /comm == "mem_check"/{
printf("malloc size: %dn", arg0);
}
uretprobe:/lib/x86_64-linux-gnu/libc.so.6:malloc /comm == "mem_check"/{
printf("addr = %pn", retval);
}
uprobe:/lib/x86_64-linux-gnu/libc.so.6:free /comm == "mem_check"/{
printf("free addr = %pn", arg0);
}
END {
printf("end proben");
}
運行結(jié)果：
探測內(nèi)存泄露
上面我們已經(jīng)探測到了mem_check中的malloc，free情況。我們可以通過malloc和free的地址集合差，就可以得到內(nèi)存泄露的地址位置。
bpftrace底層使用的是eBPF的map作為存儲結(jié)構(gòu)，可以簡單的看作K-V存儲，我們可以利用map來統(tǒng)計地址集合差，步驟如下：
- 定義一個map變量@mem：保存malloc返回的內(nèi)存地址。
- 當(dāng)探測到free調(diào)用時，將@mem對應(yīng)地址刪除。
- 最后@mem剩下的就是內(nèi)存泄露的地址。
內(nèi)存泄露檢測腳本如下：
printf("start proben");
}
uprobe:/lib/x86_64-linux-gnu/libc.so.6:malloc /comm == "mem_check"/{
printf("malloc size: %dn", arg0);
@size = arg0;
}
uretprobe:/lib/x86_64-linux-gnu/libc.so.6:malloc /comm == "mem_check"/{
printf("addr = %pn", retval);
@mem[retval] = @size;
}
uprobe:/lib/x86_64-linux-gnu/libc.so.6:free /comm == "mem_check"/{
printf("free addr = %pn", arg0);
delete(@mem[arg0]);
}
END {
printf("end proben");
}
運行結(jié)果：
如上圖，紅色框中就是沒有釋放的內(nèi)存和內(nèi)存大小。
總結(jié)
通過編寫一些簡單的bpftrace腳本，我們就可以監(jiān)視應(yīng)用程序的內(nèi)存分配和釋放事件，捕獲內(nèi)存泄漏的跡象。這種直接的實時監(jiān)控方式，使得開發(fā)者能夠在問題出現(xiàn)時即刻獲得反饋，從而更加迅速地解決潛在的內(nèi)存問題，提升軟件的穩(wěn)定性和性能。
-
內(nèi)存
+關(guān)注
關(guān)注
8文章
2902瀏覽量
73534 -
代碼
+關(guān)注
關(guān)注
30文章
4670瀏覽量
67761 -
Valgrind
+關(guān)注
關(guān)注
0文章
9瀏覽量
6779
發(fā)布評論請先 登錄
相關(guān)推薦
解構(gòu)內(nèi)核源碼eBPF樣例編譯過程
基于ebpf的性能工具-bpftrace腳本語法
關(guān)于 eBPF 安全可觀測性，你需要知道的那些事兒
openEuler 倡議建立 eBPF 軟件發(fā)布標(biāo)準(zhǔn)
eBPF是什么以及eBPF能干什么
介紹eBPF針對可觀測場景的應(yīng)用
openEuler倡議建立eBPF軟件發(fā)布標(biāo)準(zhǔn)
Linux 內(nèi)核：eBPF優(yōu)勢和eBPF潛力總結(jié)
什么是eBPF，eBPF為何備受追捧？
eBPF的前世今生？eBPF在使用中遇到的問題有哪些？
基于ebpf的性能工具-bpftrace
ebpf的快速開發(fā)工具--libbpf-bootstrap
eBPF動手實踐系列三：基于原生libbpf庫的eBPF編程改進方案簡析
工商網(wǎng)監(jiān)
評論