项目

一般

简介

错误 #4988

coredump处理整改

由 宋 承立 在 大约 2 个月 之前添加. 更新于 14 天 之前.

状态:
已解决
优先级:
一般
指派给:
孙 浩
开始日期:
2026-03-09
计划完成日期:
% 完成:

0%

预期时间:
问题归属:
BaseService, CU, DU, LogWriter
发现问题版本:
Rel_3.2.1
目标解决问题版本:
Rel_3.2.2

描述

1.各模块可考虑对coredump文件进行有效性输出，而不是全量输出
2.提取关键信息，需要考虑规避卡顿的可能（如果第一条完成后，Core文件在50M左右，可以忽略第二条）
3.baseService输出Coredump文件(如果第一条完成后，LogWriter，gnb_agent)

文件

coredump生成截图1.jpg (129 KB) coredump生成截图1.jpg 孙 浩, 2026-04-21 20:29
coredump生成截图2.jpg (115 KB) coredump生成截图2.jpg 孙 浩, 2026-04-21 20:29

历史记录

#1

由 宋 承立 更新于 大约 2 个月 之前

  • 指派给 被设置为 宋 承立
#2

由 宋 承立 更新于 大约 2 个月 之前

  • 状态 从 新建 变更为 进行中
#3

由 宋 承立 更新于 大约 2 个月 之前

  • 主题 从 baseService coredump处理整改 变更为 coredump处理整改
#4

由 宋 承立 更新于 26 天 之前

  • 状态 从 进行中 变更为 转测试
  • 指派给 从 宋 承立 变更为 王 旭初
  • 问题归属 CU, DU, LogWriter 已添加

【需求原因】
基站EMMC硬盘寿命有限，可用读写次数较少。coredump文件过大，有效信息只占很小的部分，缩小core文件大小以节约emmc寿命。

【修改方案】
1、读取/proc/self/maps中内存映射信息，对大于10M的匿名内存调用madvise将属性设置为MADV_DONTDUMP，在coredump生成时操作系统不会将这样的内存写入core文件中
注册段错误信号、异常终止信号、算数异常信号、非法指令信号和总线错误信号，在信号处理函数中进行处理和设置标志位。
DU内存大，在申请完之后调用了一次。

2、合入后core文件变化
CU：从800M降低至17M左右
DU：从4.9G降低至80M左右
baseService和logWriter在20M以内

【回归方法和注意事项】
1、pkill -11 [进程名]，发送段错误信号制造coredump
2、在后续版本使用中持续观察CU、DU、baseServicehe和LogWriter的coredump情况

#5

由 王 旭初 更新于 26 天 之前

  • 跟踪 从 需求CR 变更为 错误
  • 项目 从 研发产品测试 变更为 3.0基站产品测试
  • 指派给 从 王 旭初 变更为 孙 浩
#6

由 孙 浩 更新于 25 天 之前

待在3.2.2版本统一测试。

#7

由 孙 浩 更新于 14 天 之前

在Rel_3.2.2_Pre1T1版本，通过“pkill -11 [进程名]”构造gnb_cu、baseService、logWriter生成coredump文件，文件大小整体符合预期；
但是gnb_du生成的coredump文件有300M多，与研发宋承立沟通目前符合预期，后续还可再优化，再优化问题后续在新单子跟踪。

研发预期coredump文件大小：
CU：从800M降低至17M左右
DU：从4.9G降低至80M左右
baseService和logWriter在20M以内


导出 Atom PDF