项目

一般

简介

性能 #3266

600ue时，定时器处理能力是否为性能瓶颈

由 席 振斌 在 大约 2 个月 之前添加. 更新于 大约一个月 之前.

状态:
已关闭
优先级:
普通
指派给:
孙 浩
开始日期:
2025-04-29
计划完成日期:
% 完成:

0%

预期时间:
问题归属:
CU
发现问题版本:
Rel_3.1.2
目标解决问题版本:
Rel_3.1.2

文件

20250519-143546.jpg (605 KB) 20250519-143546.jpg 席 振斌, 2025-05-19 14:36
20250519-perf.jpg (50.9 KB) 20250519-perf.jpg 席 振斌, 2025-05-19 14:40
600ue 定时器.xlsx (14.9 KB) 600ue 定时器.xlsx 席 振斌, 2025-05-19 14:44
test.rar (59.7 KB) test.rar 席 振斌, 2025-05-19 14:44

相关的问题

关联到 3.0基站产品测试 - 性能 #3354: 优化cu的启动时间到f1ap建立成功的时间(4s->1s)已解决2025-05-19

Actions

历史记录

#1

由 席 振斌 更新于 大约 2 个月 之前

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

由 席 振斌 更新于 大约一个月 之前

通过demo程序,模拟600ue，触发当前cu程序的各个新、老定时器，经过多次测试，通过htop观察cpu，发现dl_thread和ue_cntrl_thread的线程cpu占用较高，如下图所示

然后通过perf工具，解析perf.data文件分析，主要是ianctive定时器超时后的释放流程中，在各个线程new消息时，new本身会耗费cpu，如下图所示：

结论：new timer和old timer两种定时器在6ooue时，本身的处理能力不会成为性能瓶颈，但是对于一次性释放一个小区中的600ue，这种场景，cu侧ue释放流程中new消息时会拉高cpu，在600ue时需要优化，这个后续在新单中进行优化

#3

由 席 振斌 更新于 大约一个月 之前

#4

由 席 振斌 更新于 大约一个月 之前

  • 状态 从 进行中 变更为 转测试
  • 指派给 从 席 振斌 变更为 孙 浩
#5

由 席 振斌 更新于 大约一个月 之前

  • 关联到 性能 #3354: 优化cu的启动时间到f1ap建立成功的时间(4s->1s) 已添加
#6

由 孙 浩 更新于 大约一个月 之前

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

由 孙 浩 更新于 大约一个月 之前

  • 状态 从 已解决 变更为 已关闭

导出 Atom PDF