dpdk 进程持续重启触发 /var/run 目录空间满问题分析

longyu_wlz

于 2024-07-17 10:47:07 发布

阅读量407

点赞数 13

分类专栏： dpdk 问题定位文章标签： dpdk dpdk-19.11 fbarray run 满

本文链接：https://blog.csdn.net/Longyu_wlz/article/details/140488411

版权

dpdk 问题定位专栏收录该内容

33 篇文章 16 订阅

订阅专栏

问题描述

dpdk 版本：19.11

/var/run/dpdk/vpp 目录下有大量如下内容：

root@admin-PC:~# ls /var/run/dpdk/vpp/
config                        fbarray_memseg-2048k-0-2      hugepage_info                 mp_socket_25164_bbb8fd9b1fea
fbarray_memseg-2048k-0-0      fbarray_memseg-2048k-0-2_454  mp_socket                     mp_socket_29403_bbbaf2aa28a0
fbarray_memseg-2048k-0-0_454  fbarray_memseg-2048k-0-3      mp_socket_1212_bbbc464f20f3   mp_socket_454_bbcb64b5af97
fbarray_memseg-2048k-0-1      fbarray_memseg-2048k-0-3_454  mp_socket_18581_bbb5a08fce23  mp_socket_6288_b5fd127b2cc1
fbarray_memseg-2048k-0-1_454  fbarray_memzone               mp_socket_22647_bbb79f600a6c  mp_socket_7617_b5fd86154599
root@admin-PC:~# ls /var/run/dpdk/vpp/

fbarray_memseg-xxx 文件占用了主要的空间，这些文件随着进程的重启不断增加，最后将 /var/run 空间填满。

原理分析

dpdk 程序正常启动时，会在 /run 目录中创建 fbarray_memseg-xxx 文件用来管理大页内存的分配，primary 进程创建唯一的文件，secondary 进程使用 pid 区分创建各自的文件（内部问题修改加入了 tsc ）。正常运行时占用信息如下：

root@longyu-virtual-machine:/home/longyu# lsof /var/run/dpdk/rte/fbarray_mem*
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
testpmd   3064 root  mem-R  REG   0,25  3694592 1735 /run/dpdk/rte/fbarray_memzone
testpmd   3064 root  mem-R  REG   0,25   397312 1736 /run/dpdk/rte/fbarray_memseg-2048k-0-0
testpmd   3064 root  mem-R  REG   0,25   397312 1737 /run/dpdk/rte/fbarray_memseg-2048k-0-1
..........................................................................................
dpdk-proc 3414 root  mem-R  REG   0,25  3694592 1735 /run/dpdk/rte/fbarray_memzone
dpdk-proc 3414 root  mem-R  REG   0,25   397312 1736 /run/dpdk/rte/fbarray_memseg-2048k-0-0
dpdk-proc 3414 root  mem-R  REG   0,25   397312 1737 /run/dpdk/rte/fbarray_memseg-2048k-0-1
dpdk-proc 3414 root  mem-R  REG   0,25   397312 1738 /run/dpdk/rte/fbarray_memseg-2048k-0-2
dpdk-proc 3414 root  mem-R  REG   0,25   397312 1739 /run/dpdk/rte/fbarray_memseg-2048k-0-3
dpdk-proc 3414 root  mem-R  REG   0,25   397312 1945 /run/dpdk/rte/fbarray_memseg-2048k-0-3_3414_e570cef7ed0
dpdk-proc 3414 root  mem-R  REG   0,25   397312 1944 /run/dpdk/rte/fbarray_memseg-2048k-0-2_3414_e570cea6b90
dpdk-proc 3414 root  mem-R  REG   0,25   397312 1943 /run/dpdk/rte/fbarray_memseg-2048k-0-1_3414_e570ce56e88
dpdk-proc 3414 root  mem-R  REG   0,25   397312 1942 /run/dpdk/rte/fbarray_memseg-2048k-0-0_3414_e570cdfa2a8
dpdk-proc 3414 root   10uR  REG   0,25  3694592 1735 /run/dpdk/rte/fbarray_memzone
...........................................................................................

primary 进程占用自己创建的 fbarray_xxx 文件，secondary 进程占用自己创建的以及 primary 进程创建的 fbarray_xxx 文件。

rte_eal_init 函数初始化时会调用 eal_clean_runtime_dir 来清理 /var/run 动态目录中创建的一些文件残留，其处理逻辑如下：

打开 runtime_dir 并获取互斥文件锁，避免竞争
遍历目录，使用 fnmatch 匹配如下前缀的文件名：

fbarray_

mp_socket_
对于匹配到的文件名，尝试以非阻塞模式获取文件互斥锁，获取成功则移除文件

其核心逻辑在于，回收操作在初始化后期执行，dpdk 正常运行期间会获取到 fbarray_、mp_socket_ 的文件锁，此时如果尝试获取互斥锁并设置非租塞模式，会因为有进程占用文件而失败，这样就可以判断出哪些文件属于残留文件并进行回收动作，避免程序多次启动，导致 runtime_dir 占用过大。

实现原理中存在的问题

当 dpdk 程序调用 rte_eal_init 函数时，在异常情况下并不保证能够执行到 eal_clean_runtime_dir。当因为各种异常导致 rte_eal_init 函数在创建了 fbarray-xxx 文件后，调用 eal_clean_runtime_dir 函数前退出，那这些残留文件就不会被回收，除非下一次成功 rte_eal_init。如果进程持续被调用，每次都从这里描述的异常点退出，许多次后 fbarray-xx 文件的数量就会很多，每个都要占据存储空间，最后就会把 /run 目录给存满。

问题解决方法分析

需要解决 rte_eal_init 函数异常执行的问题还是 eal_clean_runtime_dir 函数没有调用到的问题？

直接原因是 rte_eal_init 函数异常执行，解决了这个问题就不会存在因为 dpdk 进程创建了过多文件导致 /run 空间占满。

仅仅调整 eal_clean_runtime_dir 函数在 rte_eal_init 中的位置——从最后调整到最前面，不会出现 /run 空间占满的问题，但是仍旧需要解决 rte_eal_init 函数执行失败的问题。

既然 rte_eal_init 函数执行失败的问题都必须要解决，而它又是这个问题出现的前提，这样再去调整 eal_clean_runtime_dir 函数在 rte_eal_init 函数中的位置就没太大意义
dpdk 高版本是否在这块逻辑上有调整？

对比了 dpdk v24.07-rc1 版本代码，这块逻辑没有变化，eal_clean_runtime_dir 函数的位置仍旧放在 rte_eal_init 函数执行末尾
调整 eal_clean_runtime_dir 函数执行位置的可行性

eal_clean_runtime_dir 调用点有如下注释内容：
```
	/*
	 * Clean up unused files in runtime directory. We do this at the end of
	 * init and not at the beginning because we want to clean stuff up
	 * whether we are primary or secondary process, but we cannot remove
	 * primary process' files because secondary should be able to run even
	 * if primary process is dead.
	 *
	 * In no_shconf mode, no runtime directory is created in the first
	 * place, so no cleanup needed.
	 */
```
可以看到，此函数放在 rte_eal_init 函数执行后面调用是为了让 secondary 进程能够在 primary 进程已经死亡的情况下继续运行。secondary 进程也要映射 primary 进程的 fbarray_* 文件，这个动作在 rte_eal_init 中间，如果 eal_clean_runtime_dir 在此前执行，primary 进程的 fbarray_* 文件就会被释放，这样 secondary 进程就无法再运行。

我司使用场景中 primary 进程已经死亡时，secondary 运行会处于异常状态，调整此位置不影响我司对 dpdk 的使用。

primary 进程异常死亡后 secondary 进程继续运行测试

l2fwd 进程运行后，kill -9 杀掉

root@longyu-virtual-machine:/home/longyu/fbarray_remove_test# ps aux |grep l2fwd
root       11374 29.3  0.2 67537980 19128 pts/1  Tl   11:03   0:03 ./l2fwd -- -p0x1
root       11382  0.0  0.0  12116   652 pts/1    S+   11:03   0:00 grep --color=auto l2fwd
root@longyu-virtual-machine:/home/longyu/fbarray_remove_test# kill -9 11374

运行 secondary 进程

root@longyu-virtual-machine:/home/longyu/fbarray_remove_test# ./dpdk-procinfo --proc-type=secondary -- -p0x1 --stats
EAL: Detected 4 lcore(s)
EAL: Detected 1 NUMA nodes
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket_11383_c3534056eb12
EAL: failed to send to (/var/run/dpdk/rte/mp_socket) due to Connection refused
EAL: Fail to send request /var/run/dpdk/rte/mp_socket:bus_vdev_mp
vdev_scan(): Failed to request vdev from primary
EAL: Selected IOVA mode 'PA'
EAL: Probing VFIO support...
EAL: failed to send to (/var/run/dpdk/rte/mp_socket) due to Connection refused
EAL: Fail to send request /var/run/dpdk/rte/mp_socket:eal_vfio_mp_sync
EAL:   cannot request default container fd
EAL: VFIO support could not be initialized
EAL: PCI device 0000:02:01.0 on NUMA socket -1
EAL:   Invalid NUMA socket, default to 0
EAL:   probe driver: 8086:100f net_e1000_em
EAL: PCI device 0000:02:06.0 on NUMA socket -1
EAL:   Invalid NUMA socket, default to 0
EAL:   probe driver: 8086:100f net_e1000_em
EAL: Requested device 0000:02:06.0 cannot be used
EAL: Error - exiting with code: 1
  Cause: No primary DPDK process is running.

rte_eal_init 函数能够正常执行完成，程序退出原因是内部调用了检测 primary 进程是否 alive 的接口，判断到 primary 进程未在运行时直接退出。

模拟释放 primary 进程 fbarray_memseg-xxx 文件

root@longyu-virtual-machine:/home/longyu/fbarray_remove_test# rm -rf /var/run/dpdk/rte/
config                                       fbarray_memseg-2048k-0-1_11386_c3655dfc3929  fbarray_memseg-2048k-0-3_11386_c3655e113ec9
fbarray_memseg-2048k-0-0                     fbarray_memseg-2048k-0-2                     fbarray_memzone
fbarray_memseg-2048k-0-0_11386_c3655df1ca0b  fbarray_memseg-2048k-0-2_11386_c3655e058cbf  hugepage_info
fbarray_memseg-2048k-0-1                     fbarray_memseg-2048k-0-3                     mp_socket
root@longyu-virtual-machine:/home/longyu/fbarray_remove_test# rm -rf /var/run/dpdk/rte/fbarray_memseg-2048k-0-0

重新启动 secondary 进程

root@longyu-virtual-machine:/home/longyu/fbarray_remove_test# ./dpdk-procinfo --proc-type=secondary -- -p0x1 --stats
EAL: Detected 4 lcore(s)
EAL: Detected 1 NUMA nodes
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket_11390_c36f346b3ee6
EAL: failed to send to (/var/run/dpdk/rte/mp_socket) due to Connection refused
EAL: Fail to send request /var/run/dpdk/rte/mp_socket:bus_vdev_mp
vdev_scan(): Failed to request vdev from primary
EAL: Selected IOVA mode 'PA'
EAL: Probing VFIO support...
EAL: failed to send to (/var/run/dpdk/rte/mp_socket) due to Connection refused
EAL: Fail to send request /var/run/dpdk/rte/mp_socket:eal_vfio_mp_sync
EAL:   cannot request default container fd
EAL: VFIO support could not be initialized
EAL: Cannot attach to primary process memseg lists
EAL: FATAL: Cannot init memory
EAL: Cannot init memory
PANIC in main():
Cannot init EAL
5: [./dpdk-procinfo(+0x9ad19) [0x56474289ad19]]
4: [/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0x7f85c1852083]]
3: [./dpdk-procinfo(main+0x18f) [0x56474289ee3a]]
2: [./dpdk-procinfo(__rte_panic+0xd3) [0x564742d252c1]]
1: [./dpdk-procinfo(rte_dump_stack+0x27) [0x564742d2516e]]
Aborted (core dumped)

rte_eal_init 无法正常运行，直接 panic。

初步结论

高优先级修改：

出现相关问题时分析解决 rte_eal_init 函数执行失败的问题

低优先级修改：

调整 rte_eal_init 中的 clean 到函数起始位置

longyu_wlz

关注

13
点赞
踩
15

收藏

觉得还不错? 一键收藏
0
评论
dpdk 进程持续重启触发 /var/run 目录空间满问题分析

secondary 进程也要映射 primary 进程的 fbarray_* 文件，这个动作在 rte_eal_init 中间，如果 eal_clean_runtime_dir 在此前执行，primary 进程的 fbarray_* 文件就会被释放，这样 secondary 进程就无法再运行。既然 rte_eal_init 函数执行失败的问题都必须要解决，而它又是这个问题出现的前提，这样再去调整 eal_clean_runtime_dir 函数在 rte_eal_init 函数中的位置就没太大意义。
复制链接

扫一扫