VPP 内存泄漏定位跟踪

2023-09-05 17:55:10 浏览数 (2)

VPP 支持内存跟踪,可以用来帮助定位内存泄漏问题。每次内存分配或释放都会记录下来,记录内存分配的函数调用堆栈信息、跟踪维护分配数量、分配次数及当前全局分配的大小。

查看内存跟踪可以帮助诊断内存在何处过度使用及是否存在泄漏问题,并且比较不同时间点的内存跟踪可以帮助诊断是否以及在何处发生内存泄漏。

下面是在main-heap上启用内存跟踪:

代码语言:javascript复制
#内存跟踪命令行信息
vpp# memory-trace ?
  memory-trace                             memory-trace on|off [api-segment]
                  [stats-segment][main-heap][numa-heap <numa-id>]
#在main-heap启用内存跟踪
vpp# memory-trace on main-heap
代码语言:javascript复制
代码语言:javascript复制
在接口上使能dhcp clinet功能并查询内存跟踪信息如下:
代码语言:javascript复制
vpp# show memory main-heap
Thread 0 vpp_main
  base 0x7fb8878c5000, size 1g, locked, unmap-on-destroy, traced, name 'main heap'
    page stats: page-size 4K, total 262144, mapped 2839, not-mapped 246786, unknown 12519
      numa 0: 2839 pages, 11.09m bytes
    total: 1023.99M, used: 56.96M, free: 967.04M, trimmable: 967.02M

  Bytes    Count     Sample   Traceback
    14200        1 0x7fb88b1b6580 0x7fb8c80c51df
                                  0x7fb8c80c3e0a
                                  ip4_mtrie_16_route_add   0x16f
                                  fib_entry_src_action_install   0xd4
                                  fib_entry_src_action_activate   0x210
                                  fib_entry_create_special   0x3c
                                  fib_table_entry_special_dpo_add   0x154
                                  fib_table_entry_special_add   0x5c
                                  0x7fb8c80ba287
                                  0x7fb8c80a3858
                                  0x7fb8861816e4
                                  0x7fb8c96a57f3
     2192        2 0x7fb88b1b5b40 vlib_get_next_frame_internal   0x125
                                  vlib_buffer_enqueue_to_next_fn_hsw   0x2fc2
                                  ip4_input_no_checksum_node_fn_hsw   0x18e5
                                  0x7fb8c7cc6989
                                  0x7fb8c7cc4f35
                                  0x7fb8c7d3138b
                                  0x7fb8c7c47014
     1880        1 0x7fb88b1b00a0 fib_path_create   0x1ba
                                  fib_path_list_create   0x6c
                                  0x7fb8c86bb09e
                                  fib_entry_src_action_path_swap   0x18f
                                  fib_entry_create   0x51
                                  fib_table_entry_update   0x1b3
                                  fib_table_entry_update_one_path   0xe2
                                  0x7fb8c80ba243
                                  0x7fb8c80a3858
                                  0x7fb8861816e4
                                  0x7fb8c96a57f3
                                  0x7fb8c9697af6
代码语言:javascript复制
代码语言:javascript复制
内存跟踪信息记录了分配内存的字节大小,分配次数及函数调用的堆栈信息,我们通过分析代码来确认当前是否存在内存泄漏。
代码语言:javascript复制

在VPP代码中默认内存分配依赖于 VPP main-heap上,但是在使用外部库时,尤其是在插件中(例如 IKEv2 插件使用的 OpenSSL 库),这些外部库通常使用标准 libc malloc()/free()/… 调用来管理内存。这反过来又利用了默认的 libc 堆。VPP 不了解该堆,无法使用内存跟踪等工具。

为了能够使用标准 VPP 调试工具,该库将标准 libc 内存管理调用替换为使用 VPP 主堆的版本。

要使用它,我们需要使用LD_PRELOAD机制,如下:

代码语言:javascript复制
~# LD_PRELOAD=/usr/lib/x86_64-linux-gnu/libvppmem_preload.so /usr/bin/vpp -c /etc/vpp/startup.conf

上面翻译于vpp文档资料:https://fd.io/docs/vpp/v2101/troubleshooting/mem.html

代码语言:javascript复制

上周在生产环境上就遇到vpp内存泄漏被OOM kill掉的问题的。通过使用memory-trace功能很快定位到问题根因。生产环境中使用的vpp低版本,和当前还是存在一些差异,只要存在内存申请不释放都会在show memory命令行中显示出来的。

0 人点赞