项目

一般

简介

错误 #2657

【16P_pre1T1】E500模拟128用户运行60km/h移动速度并灌包，DU出现内存问题挂死

由 郝 雷 在 4 个月 之前添加. 更新于 3 个月 之前.

状态:
已解决
优先级:
普通
指派给:
郝 雷
开始日期:
2025-01-06
计划完成日期:
% 完成:

0%

预期时间:
问题归属:
DU
发现问题版本:
Rel_2.1.16P
目标解决问题版本:
Rel_2.1.16P
FPGA板卡类型:
CPU类型:

描述

E500模拟128个用户，接入后所有用户模拟60km/h的fast fading模型，上下行灌包2M每用户。
由于移动时SIR降低，多个UE掉线重接，PHY上出现APIErr，
1月 06 10:49:22 yzrt run.sh3255: DU2PHY_API_USE_NULL_DATA: phyInstance0 ApiErr_NUM20
1月 06 10:49:22 yzrt run.sh3255: [FATAL][STOP_PHY] DU2PHY_API_USE_NULL_DATA: phyInstance0 ApiErr_NUM21
1月 06 10:49:22 yzrt run.sh3255: [FATAL][STOP_PHY] DU2PHY_API_USE_NULL_DATA: phyInstance0 ApiErr_NUM21

DU上答应内存错误，
1月 06 11:07:31 yzrt run.sh9785: cmGetMemBlkSetForAlloc failed 2
1月 06 11:07:31 yzrt run.sh9785: cmGetMemBlkSetForAlloc failed 2
1月 06 11:07:31 yzrt run.sh9785: cmGetMemBlkSetForAlloc failed 2
1月 06 11:07:31 yzrt run.sh9785: cmGetMemBlkSetForAlloc failed 2
1月 06 11:07:31 yzrt run.sh9785: cmGetMemBlkSetForAlloc failed 2
1月 06 11:07:31 yzrt run.sh9785: cmGetMemBlkSetForAlloc failed 2
1月 06 11:07:31 yzrt run.sh9785: cmGetMemBlkSetForAlloc failed 2
1月 06 11:07:31 yzrt run.sh9785: cmGetMemBlkSetForAlloc failed 2
1月 06 11:07:31 yzrt run.sh9785: cmGetMemBlkSetForAlloc failed 2
1月 06 11:07:31 yzrt run.sh9785: cmGetMemBlkSetForAlloc failed 2
1月 06 11:07:31 yzrt run.sh9785: cmGetMemBlkSetForAlloc failed 2
1月 06 11:07:31 yzrt run.sh9785: cmGetMemBlkSetForAlloc failed 2
1月 06 11:07:31 yzrt run.sh9785: cmGetMemBlkSetForAlloc failed 2
1月 06 11:07:31 yzrt run.sh9785: cmGetMemBlkSetForAlloc failed 2
1月 06 11:07:31 yzrt run.sh9785: cmGetMemBlkSetForAlloc failed 2
1月 06 11:07:31 yzrt run.sh9785: cmGetMemBlkSetForAlloc failed 2
1月 06 11:07:31 yzrt run.sh9785: cmGetMemBlkSetForAlloc failed 2

几分钟后DU挂死。

文件

6xaipEKWar.jpg (101 KB) 6xaipEKWar.jpg 匿名用户, 2025-01-15 09:58
8K8DX4Vsk3.jpg (59.3 KB) 8K8DX4Vsk3.jpg 匿名用户, 2025-01-15 10:00
7Immq0aRE4.jpg (391 KB) 7Immq0aRE4.jpg 匿名用户, 2025-01-15 10:03
WO5fdFw2bN.jpg (891 KB) WO5fdFw2bN.jpg 匿名用户, 2025-01-21 13:48
z2Ali0FYYO.jpg (177 KB) z2Ali0FYYO.jpg 匿名用户, 2025-01-21 13:52

历史记录

#1

由 匿名用户 更新于 4 个月 之前

场景：高速移动，pdcch聚合等级自适应开关打开，大上行子帧配比
UE的cqi都很差，选取的pdcch聚合等级都是4，根据大上行的子帧配比，每tti调度4用户计算需要的cce总数为 4*4*10 = 160CCE，而大上行子帧配比单符号的CCE总数为3*32 = 96CCE，CCE总数远远不够，日志中有很多的pdcch资源分配失败，资源分配失败后可能存在未及时释放的问题，导致后续的内存耗尽，DU挂死。
修改coreset1占用符号数为2符号后，CCE总数为3*32*2 = 192CCE > 160CCE，测试30分钟，未出现内存耗尽和挂死现象，但是出现高误码和低速率的问题，
测试单UECORESET1配置2symbol，发现同样存在高误码和低速率的问题
关联问题单#2660

#2

由 匿名用户 更新于 4 个月 之前

该问题暂等解决#2660后进一步观察

#3

由 匿名用户 更新于 4 个月 之前


查看DU memory_log之后发现大小为8192的内存块耗尽且出现分配失败的统计

进一步定位发现在使用8192的内存中size为2632的count过多，查看前后的统计日志，发现该size大小的内存只申请，未释放，所以怀疑该内存块大小的内存存在泄漏

查看du_log后找出代码中具体的内存泄漏的结构体为RgRguDedDatInd；

#4

由 匿名用户 更新于 4 个月 之前

走读代码发现RgRguDedDatInd确实存在未释放的场景，但是没有异常日志打印(未释放的地方都有异常日志)，发现日志中在pdcch分配失败的时候有时序错乱的打印

内存耗尽时因为在聚合等级都选择4的场景下，pdcch很多分配失败，因为当前tti的某个UE的pdcch分配失败的话会继续从重传/新传队列中取下一个UE分配pdcch，因为资源有限的原因，pdcch在当前tti一直分配失败，耗时过多，导致的时序错乱，从而导致用户面数据未及时释放或出现坏内存，引起内存耗尽
参照下行的处理方式，上行和下行的pdcch连续分配失败达到一定次数之后不再继续分配，避免pdcch连续分配失败，反复分配造成lvl1和lvl2的时序错乱。
该修改属于针对pdcch资源不足，分配失败的鲁棒性保证。
pdcch的分配方式修改跟踪在问题单#2727和#2660

#5

由 匿名用户 更新于 3 个月 之前

  • 状态 从 新建 变更为 转测试
  • 指派给 从 匿名用户 变更为 郝 雷

和入#2660 #2727后该问题不在出现；
代码落入17P

#6

由 郝 雷 更新于 3 个月 之前

  • 状态 从 转测试 变更为 已解决

导出 Atom PDF