节点报错-4013，sqlexecutor模块周期性打高到5G

[李元锴]

【 使用环境 】生产环境
【 OB or 其他组件 】
OB
【 使用版本 】
4.3.5.6

【问题描述】清晰明确描述问题
租户规格 5c11g，应用报错-4013，通过gv$ob_memory视图看，sqlexecutor模块占用内存高

按内存问题诊断步骤：

1.  开启内存诊断：
   

开启抓取指定模块SqlExecutor的内存；
alter system set leak_mod_to_check=‘SqlExecutor’;
2. 发起业务：过几分钟后
3. 采集内存：
获取所有节点ResultSet模块内存占用情况：
select * from __all_virtual_mem_leak_checker_info order by alloc_count desc;

打印前2个占用1.2G的back_trace堆栈：
addr2line -pCfe /home/admin/oceanbase/bin/observer
第一个结果

第二个结果

【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

[论坛小助手]

根据您的描述，您遇到的问题是租户在执行SQL时出现错误（错误码-4013），并且观察到 sqlexecutor 模块内存占用较高。针对这种情况，我们推荐使用 obdiag 工具进行进一步的日志采集和根因分析。

日志采集场景: 内存问题
日志采集命令:

obdiag gather scene run --scene=observer.memory

该命令将会收集与内存相关的系统信息，帮助定位问题。

同时，考虑到您提到的错误代码-4013以及高内存占用的情况，建议也进行以下根因分析：
根因分析场景: 事务其他错误
根因分析命令:

obdiag rca run --scene=transaction_other_error

这条命令将基于收集的数据尝试自动识别导致事务异常的具体原因。

请您运行上述命令，并将生成的日志文件压缩包提供给我们以便进一步分析问题所在。在此之前，为了更准确地了解状况，请您先回答以下几个问题：

1. 发生此问题前是否对数据库进行了任何配置更改或升级？
2. 错误发生时，是否有大量的并发查询或大型数据操作正在执行？
3. 在错误发生前后，系统的总体负载情况如何？特别是CPU、内存和磁盘I/O的使用率。
4. 是否有记录到完整的错误日志或者堆栈跟踪信息可以分享？
5. 出现问题的应用程序部分代码能否提供参考，尤其是涉及到的那个SQL语句？

这些问题的答案将有助于我们更快地理解背景并找到解决问题的方法。期待您的回复！

附上敏捷诊断工具 obdiag 使用帮助链接

[李元锴]

通过上面的文件上传功能，上传obdiag gather scene run --scene=observer.memory的结果文件报错，如何上传附件obdiag_gather_pack_20260825095151.tar.gz，大概500M

[淇铭]

文件太大了 只能上传50M 建议在压缩一下 或者分批上传

[淇铭]

你收集的堆栈信息 能否输出到一个文件里 看着有转化中文

[李元锴]

我将文件split切割成50m大小的块，一样无法上传
split -b 50M -d obdiag_gather_pack_20260825095151.tar.gz obdiag_gather_pack_20260825095151.part
将后缀改为.txt上传报错

[李元锴]

是没有安装debug包，所以显示？的吧，中文“于”字正常显示的呢，开源版找不到对应的debug包下载地址

[淇铭]

装一下debuginfo包 下载对应的版本 debuginfo包可以在阿里云上找到（oceanbase-community-stable-el-7-x86_64安装包下载_开源镜像站-阿里云

rpm2cpio oceanbase-debuginfo-xxx.el7.x86_64.rpm | cpio -div
将解压出的observer.debug 文件拷贝进observer目录，默认为/home/admin/oceanbase/bin目录

[淇铭]

你上传到这个里面https://upfile.live/ 我在下载看看