20260630版本redfish查询sel信息耗时偏久

交流互助区
1

// 此模板仅供参考，如果不适用可以修改

问题描述

/redfish/v1/Managers/1/LogServices/SEL/Entries 查询耗时偏久。

image
image985×506 29.8 KB

image
image971×785 43.1 KB

环境信息

  • 软件版本：OpenUBMC2606

  • 版本信息如下：

image
image692×334 8.14 KB

重现步骤

  1. [第一步] 下发uri：/redfish/v1/Managers/1/LogServices/SEL/Entries

  2. [第二步] 等待查询结果输出

期望结果

响应报文10s内输出

实际结果

响应报文40+s才输出，请确认630是做了什么调整？

2

答案内容由AI生成，仅供参考：

总结与建议

结合以上信息，26.06版本中同时存在“新增标准接口”与“sensor组件重构”两项正向调整，但也可能重新引入了或保留了JD组件的定制化覆盖。实际导致查询耗时40+s的根本原因可能是：

  1. 查询未实现分页或批量读取优化，导致全量SEL条目一次性返回。
  2. 定制化逻辑未完全删除，对每个条目都执行了额外处理。
  3. 重构后的查询路径存在性能回退（如数据库查询未命中缓存）。
  4. SEL条目数量过多（但40s表明更可能是实现问题而非单纯数据量问题）。

建议排查方向（基于上下文）：

  • 检查Redfish SEL接口的实际实现是否采用了分页（如 $top/$skip 参数），若未分页，应引导客户端使用限定查询。
  • 确认JD组件配置是否仍处于启用状态，若相关配置存在，尝试删除后重启服务。
  • 调用 Get SEL Info（IPMI或Redfish）查看当前SEL条目总数和可用空间，评估是否需要先执行 Clear SEL 减少数据量。
  • 查看 app.log 或 service.log 中SEL查询相关的请求耗时日志，定位具体慢在Redfish层还是底层存储层。

由于上下文未提供明确的版本变更日志或性能测试数据，以上分析完全基于知识库中提取的相关调整信息。如需精确根因，建议结合BMC侧的具体日志（如Redfish请求追踪、D-Bus调用日志）进一步诊断。

点击此处查看详细分析解答

根据您提供的上下文信息，OpenUBMC 26.06（即问题中提到的“20260630版本”）中涉及多项与SEL（System Event Log）相关的变更，这些调整可能直接影响了 Redfish 接口 /redfish/v1/Managers/1/LogServices/SEL/Entries 的查询性能。以下是从知识库中提取的与版本调整相关的关键信息：

1. 新增标准Redfish SEL接口

在26.06版本中，经过评审后新增了Redfish标准SEL接口，包括以下URI：

  • /redfish/v1/Managers/:managerid/LogServices/SEL
  • /redfish/v1/Managers/:managerid/LogServices/SEL/Entries
  • /redfish/v1/Managers/:managerid/LogServices/SEL/Entries/:entriesid

该接口定义了 MaxNumberOfRecords（默认值2000）、LogEntryType（固定为 SEL）等属性，并规定了只读权限。新增标准化接口可能改变了底层查询逻辑或数据封装方式，若实现中对大量条目（如数千条记录）缺乏高效的批量读取或分页机制，容易导致响应时间大幅上升（从期望的10s暴增至40+s）。（参考Search Result id=1）

2. sensor组件C++重构与SEL性能目标

同一版本中，openUBMC sensor组件进行了C++重构，设计目标中包含多项与SEL相关的性能提升：

  • SEL写入吞吐提升 >= 2x
  • SEL写入P99延迟降低 >= 40%
  • SEL查询无效记录扫描比例下降 >= 70%

该重构旨在优化数据库访问层，分离查询/写入执行器，并采用预编译语句缓存、批量事务、单写线程等手段。理论上查询效率应提升，但实际效果取决于实现是否完整覆盖所有查询场景。若重构后查询路径发生了变化（如增加了新的过滤或统计逻辑），或重构后的接口与Redfish服务间的协作存在瓶颈，仍可能造成查询缓慢。（参考Search Result id=6）

3. 社区JD组件定制化覆盖SEL接口

在OpenUBMC的早期版本（25.06前后）已有反馈指出，社区JD组件对 /redfish/v1/Managers/1/LogServices/SEL 接口做了定制化实现，导致原标准接口的逻辑被覆盖，进而引发功能异常。该问题在当时的解决方案是删除JD组件的相关配置以恢复标准行为。
若26.06版本仍沿用或更新了此类定制化逻辑（例如在标准接口基础上附加了数据处理、权限校验或额外的日志记录），这些额外操作会显著增加每次查询的耗时。（参考Document Chunks id=4）

4. 与SEL查询性能相关的其他上下文

  • SEL的容量与溢出状态：知识图谱中 Get SEL Info 命令返回的 Free Space、Overflow Flag 等字段可反映SEL存储区是否已满或接近极限。当SEL条目数接近最大记录数（如2000条）时，全量查询的扫描开销会很大，但40s仍属异常。
  • D-Bus调用链路：GetSelInfo 方法通过 busctl 调用 bmc.kepler.Systems.Events 接口，其响应结构在 mdb_interface 中定义。如果Redfish查询 SEL/Entries 的内部实现依赖于类似的D-Bus调用且调用频率过高，也可能成为瓶颈。

总结与建议

结合以上信息，26.06版本中同时存在“新增标准接口”与“sensor组件重构”两项正向调整，但也可能重新引入了或保留了JD组件的定制化覆盖。实际导致查询耗时40+s的根本原因可能是：

  1. 查询未实现分页或批量读取优化，导致全量SEL条目一次性返回。
  2. 定制化逻辑未完全删除，对每个条目都执行了额外处理。
  3. 重构后的查询路径存在性能回退（如数据库查询未命中缓存）。
  4. SEL条目数量过多（但40s表明更可能是实现问题而非单纯数据量问题）。

建议排查方向（基于上下文）：

  • 检查Redfish SEL接口的实际实现是否采用了分页（如 $top/$skip 参数），若未分页，应引导客户端使用限定查询。
  • 确认JD组件配置是否仍处于启用状态，若相关配置存在，尝试删除后重启服务。
  • 调用 Get SEL Info（IPMI或Redfish）查看当前SEL条目总数和可用空间，评估是否需要先执行 Clear SEL 减少数据量。
  • 查看 app.log 或 service.log 中SEL查询相关的请求耗时日志，定位具体慢在Redfish层还是底层存储层。

由于上下文未提供明确的版本变更日志或性能测试数据，以上分析完全基于知识库中提取的相关调整信息。如需精确根因，建议结合BMC侧的具体日志（如Redfish请求追踪、D-Bus调用日志）进一步诊断。

3

该问题是由于调用sensor组件中GetReportedSel方法耗时长，sensor组件已开源，可自行调试确认耗时点