【 使用环境 】测试环境
【 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收集诊断信息,详情参见链接（右键跳转查看）：
【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！
你好咨询下，是否有odp的core文件产生。
这边先复现一下
没看到core文件。
另外，我们查阅proxy层的proxy_slow.log ，我们发现有的SQL，ODP的处理时间比较大。
请问可以通过什么方式进行定位呢？
现在又不太好复现。
其实我们调整“digest_sql_length”的原因是，我们感觉proxy的耗时好像有时高，但是又说不上来。有点难提供对应的信息给你们。
另外，我认为没看到core文件，其实我们的内存是很够的。
这边正在测试复现
这边未复现成功，麻烦先提供一份obproxy停服期间的日志。
再确认一下是否有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
老师，真的，用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
建议先把参数调回去针对调大后出现的异常 后续内部再重点看一下 ，digest_sql_length与ODP耗时无关。如果存在慢sql，建议使用obdiag进行sql分析一下
意思是，我们再测试参数调大之后的状态观察测试吗？出了问题我们再进行定位吗?好的哈。
digest_sql_length我们其实也理解是和ODP耗时无关，我们也觉得不太可能影响proxy服务，主要就只是，ODP生成的proxy_digest.log的日志，想观察日志中odp耗时的情况以及对应完整的SQL。
我意思你把参数改回1024。我这边后续再测试测试复现看看
这个参数怎么会影响运行实例呢
出问题之后，就一直是 默认值。
另外咨询以下，我们将“syslog_level”调整为“WARN”后，proxy_digest.log没有输出了呢~
是需要在“WDIAG”级别才有输出吗？主要是感觉INFO好像没什么用~
另外，因为是测试环境，我们还是又尝试调整这个值，
还是能直接复现该问题了。
1、调整时间：17:33分左右
2、时不时出现obproxy进程停止告警
3、客户端连接不稳定。
4、应用端报错日志出现时断时连的情况。
建议先改回去吧如果想差sql文本可以查询GV$OB_SQL_AUDIT视图。你们的sql大概长度有多长，发一份例子看看
嗯嗯，好的。
我们这边的环境还是比较容易复现的。
另外，这个系统是相对空闲的系统，其实，并没有一直在记录sql digest日志，但是服务明显不稳定。不管从OCP监控数据上看，还是应用层面上看，还是从用户体感上看。
你好，麻烦可以提供一下你那边的sql么。这边测试下是否可以复现出来
