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

于 2024-07-17 10:47:07 发布
阅读量678 收藏 19
点赞数 17
分类专栏： dpdk 问题定位 文章标签： dpdk dpdk-19.11 fbarray run 满
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/longyu_wlz/article/details/140488411
版权

问题描述

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 动态目录中创建的一些文件残留，其处理逻辑如下：

  1. 打开 runtime_dir 并获取互斥文件锁，避免竞争

  2. 遍历目录，使用 fnmatch 匹配如下前缀的文件名：

    fbarray_

    mp_socket_

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

其核心逻辑在于，回收操作在初始化后期执行，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 目录给存满。

问题解决方法分析

  1. 需要解决 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 函数中的位置就没太大意义

  2. dpdk 高版本是否在这块逻辑上有调整？

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

  3. 调整 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 进程继续运行测试

  1. 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

  2. 运行 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 进程未在运行时直接退出。

  1. 模拟释放 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

  2. 重新启动 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
关注
专栏目录
DPDK 多进程
lingshengxiyou的博客
12-21 1297
Symmetric Multi-process Example，主进程初始化所有资源，副进程直接获取资源进行数据包处理，副进程除了不初始化资源，数据包处理和主进程是一样的。每个进程获取每个端口的一个RX， TX队列。Master-slave Multi-process Example，这个模式主要是介绍各进程之间存在依赖关系，主进程和副进程，副进程和副进程。Client-Server Multi-process Example，主进程初始化资源和接收所有收到的数据包并轮询分发给副进程处理。
一文了解DPDK RX/TX Callbacks源码
lingshengxiyou的博客
08-27 755
basicfw就是一个网口收到的包立即从另一个网口转发出去，非常简洁明了的程序，可以通过basicfw学习基础的DPDK发包API。RX / TX Callbacks 演示在接收和传输的数据包上使用用户定义的回调函数。原文链接：https://www.cnblogs.com/ZCplayground/p/9323907.html。学习地址：http://ke.qq.com/course/5066203?793599096 免费获取，或自行报名学习，免费订阅，永久学习，关注我持续更新哦！......
dpdk内存管理
qq_28440017的博客
12-01 1204
dpdk内存管理
dpdk vhost应用
lingshengxiyou的博客
11-08 438
dpdk 目录下有examples/vhost 测试使用vhost-user 的例子，相当与网卡直通到虚拟机网卡。更多DPDK相关学习资料有需要的可以自行报名学习,免费订阅,久学习,或点击这里加。先启用 gdb ./vhost-switch。创建 共享内存通道 /tmp/sock0。启动 vhost_swittch。领取,关注我持续更新哦!启用虚拟机 xml 配置添加。dpdk vhost应用。
dpdk程序启动顺序引发的血案
龙瑜的博客
04-18 537
问题描述 在某个特定的场景中，dpdk primary 进程在宿主机上运行，在 dpdk primary 进程运行前，宿主机上的某 A 程序负责创建 /dev/hugepages 目录并挂载 hugetlbfs 到此目录中。 同时在此宿主机上也以容器为基本单位指定特权模式运行其它的 dpdk secondary 进程，dpdk secondary 进程需要与 primary 进程共享的目录通过容器启动参数来映射。 容器的启动时机与 A 程序创建 /dev/hugepages 目录并挂载大页内存的时序没有严格
DPDK： 多进程
hhd1988的专栏
11-03 1117
DPDK： 多进程
OVS DPDK与QEMU之间如何通过vhost user协议通信 vhost user协议的控制和数据通道
lingshengxiyou的博客
11-16 595
netdev_dpdk_vhost_construct定义在文件openvswitch-2.9.2/lib/netdev-dpdk.c1060 {10641073 }107410811092 }10931100 }11011110 }11111117 }11181123 }11241125 out:"1130 }
国产化改造之容器迁移指导
最新发布
企业实战系列集 ●●● https://ximenjianxue.blog.csdn.net
04-28 1337
另外再回顾下底层这些东西，如上图所示，docker镜像层位于内核层之上，其中内核层中的AUFS，LXC，Bootfs（boot file system）一起为上层的镜像提供kernel内核支持；即信息技术应用创新的简称，涵盖了国产软件、国产芯片以及云计算等各个方向，也可以理解为常说的“ZZKK（自主可控）”， ZZKK是指对国内企事业单位应用系统中关键软硬件部件的安全性、可靠性、性能稳定性、安全接入等方面进行评估和测试的过程。基于此，docker镜像层+容器层，我们是可以提交成新镜像导出的；
从网络协议基础到socket连接池，搞懂tcp，http，socket，socket连接池之间的关系
Linux高级开发的博客
03-08 456
前言 ​ 作为一名开发人员我们经常会听到HTTP协议、TCP/IP协议、UDP协议、Socket、Socket长连接、Socket连接池等字眼，然而它们之间的关系、区别及原理并不是所有人都能理解清楚，这篇文章就从网络协议基础开始到Socket连接池，一步一步解释他们之间的关系。 七层网络模型 ​ 首先从网络通信的分层模型讲起：七层模型，亦称OSI(Open System Interconnection)模型。自下往上分为：物理层、数据链路层、网络层、传输层、会话层、表示层和应用层。所有有关通信的都离不
Kolla-ansible源码分析
O1564511094的博客
08-19 2733
1. 基本认识 1.1. kolla-ansible kolla-ansible是从kolla项目中分离出来的一个可交付的项目。kolla-ansible负责部署容器化的openstack各个服务和基础设施组件；而kolla项目现在则单独负责镜像的构建，为kolla-ansible部署提供生产级别的openstack各服务镜像。 1.2. ansible和docker kolla-ansi...
dpdk-16.04 解初始化过程
龙瑜的博客
04-26 623
dpdk-16.04 程序解初始化过程 dpdk-16.04 解初始化过程相对简单，这里以 l2fwd 程序的退出过程来分析。 l2fwd 程序退出过程 l2fwd 程序正常退出代码如下： for (portid = 0; portid < nb_ports; portid++) { if ((l2fwd_enabled_port_mask & (1 << portid)) == 0) continue; printf("Closing port %d...", p
DPDK内存管理（初始化+分配释放）
weixin_44376670的博客
04-14 1518
以下内容以dpdk19.11版本代码为准，其他版本可能有出入。 DPDK通过使用hugetlbfs，减少CPU TLB表的Miss次数，提高性能。 DPDK的内存初始化工作，主要是将hugetlbfs的配置的大内存页，根据其映射的物理地址是否连续、属于哪个Socket等，有效的组织起来，为后续管理提供便利。 主要init过程：//以启用了大页，legacy-mem模式为主 内存管理主结构为struct rte_mem_config* mem_config = rte_config.mem_config 内存
dpdk 内存管理
lingshengxiyou的博客
12-29 599
dpdk 使用 Linux 提供的获取大页、页表、numa 节点表、mmap 功能重新组织内存。大页： 最多可以同时存在 3 种大页。一般只是用 2M 的大页。linux 中获取大页相关信息是通过访问解析、、等内容得到的。页表： linux 中每个进程的页表对应的文件是，本进程的页表是 /proc/self/pagemap。numa 节点表： linux 中每个物理页所在的 numa socket 表对应的文件是，本进程的 numa socket 表是。
DPDK初始化分析(三)
whenloce的专栏
05-02 4373
目录 一、概述 二、流程分析 2.1eal_hugepage_info_init 2.1.1 hugepage_info_init 2.1.2create_shared_memory 2.2rte_eal_log_init 2.3rte_eal_vfio_setup 2.4rte_eal_memzone_init 2.4.1rte_fbarray_init 2.4....
DPDK : 解析内存初始化的过程
pcokk的博客
05-01 5387
这一篇文章主要是对DPDK的EAL(Environment Abstraction Layer)中内存的初始化的解析，这是DPDK内存管理的基础。 注：在DPDK中，初始化由primary process完成，而其他process统称为secondary process，其可以通过读取一些文件来获取primary process的初始化信息。DPDK采用了一种集中式控制的方式，比如在多进程的场景中...
DPDK18.11.11内存初始化流程总结
aixueai的博客
03-15 1268
前言 本篇主要是对DPDK的EAL(Environment Abstraction Layer)中内存的初始化流程进行总结，由于DPDK支持多进程应用，此篇总结主要针对primary process主进程流程进行跟踪总结，先了解下主次进程概念，如下： 1,在DPDK中，初始化由primary process完成。而其他process统称为secondary process，其可以通过读取一些文件来获取primary process的初始化信息，从而使得自身与primary process保持相同的内存映像。
DPDK编程指南-3（环境抽象层）
shaoyunzhe的专栏
04-28 1882
作者：半天妖 链接：https://www.jianshu.com/p/273e99f61e97 3. 环境抽象层 环境抽象层（EAL）为底层资源如硬件和存储空间的访问提供接口。这些接口为上层应用程序和库隐藏了不同环境的特殊性。初始化程序负责决定如何分配这些资源（即内存空间、PCI设备、计时器、控制台等扥）。 EAL提供的服务如下： DPDK的加载和启动：DPDK和特定的应用程序链接成一个...
k8s 多 pod 环境运行 dpdk 多进程问题
龙瑜的博客
10-15 1209
本文描述了 dpdk 多进程程序在 k8s 环境运行的一个问题，从 dpdk 代码实现上来看，dpdk 对这种场景的支持并不好，可能还存在其它问题。上半年我写的程序启动顺序引发的血案之 dpdk 进程死锁这篇博客描述了 dpdk 多进程共享用户态锁潜在的死锁问题，在这个场景中也存在。这些问题比较隐晦，缺少对 dpdk 底层原理的理解则很难在方案设计前期识别出来，是一个风险点。
DPDK:Programmer’s Guide(编程指南)(2 ~ 3章) 中英对照
fuzhiyu1985的专栏
03-01 2284
1. Introduction(简介)(请读自行阅读) This document provides software architecture information, development environment information and optimization guidelines. 本文档提供了软件架构信息、开发环境信息和优化指南。 For programming example...
/var/run/dpdk/rte/config
01-16
关于/var/run/dpdk/rte/config的具体介绍或演示，根据提供的引用内容中没有提到这个路径或文件，无法给出具体的介绍或演示。如果您有更多的信息或问题，请提供更多的上下文或引用内容，以便我能够更好地回答您的问题...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值