ODP,在调整digest_sql_length长度后频繁停止服务

【 使用环境 】测试环境
【 OB or 其他组件 】ODP
【 使用版本 】OBProxy 4.3.4.0-1
【问题描述】
1、ODP服务,调整digest_sql_length长度后,整个服务变得不稳定。
digest_sql_length 从 1024 调整为 102400
2、告警出现频繁OBProxy进程停止告警。

OCP监控:

3、应用端反馈链接非常不稳定。

4、proxy_digest.log 日志其实并没增加多少,因为这其实是一个相当空闲的系统。
但是,从时间点上看,确实是调整这个参数后,出现的。

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

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

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

3 个赞

你好咨询下,是否有odp的core文件产生。
这边先复现一下

2 个赞

没看到core文件。

1 个赞

另外,我们查阅proxy层的proxy_slow.log ,我们发现有的SQL,ODP的处理时间比较大。

请问可以通过什么方式进行定位呢?
现在又不太好复现。

其实我们调整“digest_sql_length”的原因是,我们感觉proxy的耗时好像有时高,但是又说不上来。有点难提供对应的信息给你们。

2 个赞

另外,我认为没看到core文件,其实我们的内存是很够的。

1 个赞

这边正在测试复现

1 个赞

这边未复现成功,麻烦先提供一份obproxy停服期间的日志。

1 个赞

proxy.log.tar.gz (26.2 MB)

麻烦老师了~

1 个赞

再确认一下是否有core文件产生,
麻烦使用 addr2line打印一下堆栈看看
addr2line -Cfe obproxy 0x10d8509 0x1100370 0x26055a2 0x1518c08df5b0 0x1518c097027a 0x140a55f 0x13f4b9d 0x13f387a 0x13abf54 0x13a6ef2 0x151dd62 0x151ff37 0x13ab1f5 0x137bdd4 0x14c6d55 0x12259fc 0x1226435 0x122e5f8 0x1222d60 0x120df7b 0x11f8e73 0x11f7598 0x1200a5e 0x1518c04711ca 0x1518c08ca8d3

1 个赞

老师,真的,用find命令找了,确实是没有core文件~

另外打印堆栈这个我不知道整错没有。

[root@test bin]# addr2line -Cfe obproxy 0x10d8509 0x1100370 0x26055a2 0x1518c08df5b0 0x1518c097027a 0x140a55f 0x13f4b9d 0x13f387a 0x13abf54 0x13a6ef2 0x151dd62 0x151ff37 0x13ab1f5 0x137bdd4 0x14c6d55 0x12259fc 0x1226435 0x122e5f8 0x1222d60 0x120df7b 0x11f8e73 0x11f7598 0x1200a5e 0x1518c04711ca 0x1518c08ca8d3
??
??:0
??
??:0
posix_memalign
??:?
??
??:0
??
??:0
posix_memalign
??:?
posix_memalign
??:?
posix_memalign
??:?
posix_memalign
??:?
posix_memalign
??:?
posix_memalign
??:?
posix_memalign
??:?
posix_memalign
??:?
posix_memalign
??:?
posix_memalign
??:?
posix_memalign
??:?
posix_memalign
??:?
posix_memalign
??:?
posix_memalign
??:?
posix_memalign
??:?
posix_memalign
??:?
posix_memalign
??:?
posix_memalign
??:?
??
??:0
??
??:0
1 个赞

建议先把参数调回去针对调大后出现的异常 后续内部再重点看一下 ,digest_sql_length与ODP耗时无关。如果存在慢sql,建议使用obdiag进行sql分析一下

1 个赞

意思是,我们再测试参数调大之后的状态观察测试吗?出了问题我们再进行定位吗?好的哈。

digest_sql_length我们其实也理解是和ODP耗时无关,我们也觉得不太可能影响proxy服务,主要就只是,ODP生成的proxy_digest.log的日志,想观察日志中odp耗时的情况以及对应完整的SQL。

1 个赞

我意思你把参数改回1024。我这边后续再测试测试复现看看

1 个赞

这个参数怎么会影响运行实例呢

出问题之后,就一直是 默认值。

另外咨询以下,我们将“syslog_level”调整为“WARN”后,proxy_digest.log没有输出了呢~

是需要在“WDIAG”级别才有输出吗?主要是感觉INFO好像没什么用~

另外,因为是测试环境,我们还是又尝试调整这个值,

还是能直接复现该问题了。
1、调整时间:17:33分左右

2、时不时出现obproxy进程停止告警

3、客户端连接不稳定。

4、应用端报错日志出现时断时连的情况。

建议先改回去吧如果想差sql文本可以查询GV$OB_SQL_AUDIT视图。你们的sql大概长度有多长,发一份例子看看