【 使用环境 】测试环境
【 使用版本 】observer:4.3.2.1 架构是1-1-1, obproxy:4.3.1.0-4 * 3 部署在observe 的三个节点上
【问题描述】obproxy 内存持续增长, 三个obproxy 均出现内存告警.proxy_mem_limited 默认设置为 2G, 告警期间查看业务租户的活跃会话并没有在执行SQL. 请帮忙看看.
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：
【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)
obp_log.zip (10.2 KB)
【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！
根据您提供的信息，您的 OBProxy 实例正在遭遇内存不足的问题，并且已经触发了告警。根据文档中的信息 [1]，当 OBProxy 的内存使用达到其限制的 90% 时，会出现类似您描述的告警信息。以下是针对您问题的一些建议：
调整 proxy_mem_limited 参数：您可以尝试增加 OBProxy 的内存限制。由于您提到当前 proxy_mem_limited 的值为 2GB，您可以考虑将其增加到更高的值，例如 8GB。这可以通过执行以下 SQL 语句实现：
ALTER proxyconfig SET proxy_mem_limited = 8G;
检查是否有业务连接：请确保当前 OBProxy 上没有正在进行的业务连接，因为某些情况下，内存的增长可能是由于长时间未断开的连接造成的 [3]。您可以通过 GV$OB_PROCESS 或者 GV$OB_PROXY_SESSION 等视图来检查当前活跃的会话。
内存泄漏排查：如果调整内存限制后问题仍然存在，建议您检查是否存在内存泄漏。可以通过设置 mem_leak_check_mod_name 和 mem_leak_check_class_name 来开启内存泄漏检测 [5]：
obclient> alter proxyconfig set mem_leak_check_mod_name='ALL';
obclient> alter proxyconfig set mem_leak_check_class_name='';
然后执行 show proxymemory 3\G 来查看内存占用情况及内存分配堆栈，以便进一步定位问题。
查看日志：OBProxy 的日志中可能会有关于内存使用情况的详细信息。特别是当内存达到告警限制（proxy_mem_limited * 80%）后，OBProxy 会主动打印内存占用最多的 10 条记录到日志中 [5]。您可以查看这些日志来获取更多信息。
优化其他配置：除了调整内存限制外，还可以考虑优化其他配置项，例如 enable_compression_protocol，将其设置为 False 可以减少 OBProxy 对 CPU 的占用 [2]：
ALTER PROXYCONFIG SET enable_compression_protocol = False;
综上所述，您可以按照以上步骤逐一排查并解决问题。如果问题依旧无法解决，建议联系 OceanBase 的技术支持团队进行更深入的诊断。
具体信息可参考以下文档:
是否为生产环境集群，建议优先扩容使用
感谢回复,已经扩容了. 目前这个环境还未正式投入使用. 我们另一套(observer: 4.2.1.7, obproxy:4.2.3.0-3)已投入使用的环境, obproxy 内存占用基本稳定在750M + 左右. 这个环境都没咋使用内存占用却超过了1.5G+ 感觉特别奇怪
补充下, obproxy 的参数没有进行任何调整, 都是使用的默认参数.
感谢您的补充信息。根据您的描述，您已经在测试环境中增加了 OBProxy 的内存限制，并且该环境尚未正式投入使用。然而，即使在这样的情况下，OBProxy 的内存占用依然较高，达到了 1.5GB 以上，而相比之下，您已投入使用的环境中 OBProxy 的内存占用基本稳定在 750MB 左右。
考虑到您的 OBProxy 在测试环境中的内存占用明显高于生产环境，这里有几个可能的原因和建议：
版本差异：您提到测试环境使用的 OBProxy 版本为 4.3.1.0，而生产环境使用的版本为 4.2.3.0-3。不同版本之间可能存在一些内部优化或 bug 修复，导致内存占用有所不同。建议您对比两个版本的发布说明，查看是否有相关的内存优化或已知问题 [7]。
配置差异：尽管您提到测试环境的 OBProxy 参数均为默认值，但还是建议您仔细检查测试环境和生产环境之间的配置差异，包括但不限于网络配置、日志级别、监控指标采集频率等。这些配置的不同也可能影响内存使用情况。
负载差异：虽然测试环境尚未正式投入使用，但请确认是否有任何后台任务或测试脚本在运行，这些任务可能会产生额外的负载，从而导致内存占用增加。此外，即使是空闲状态下的 OBProxy 也有可能因为某些内部机制（如心跳检测、健康检查等）而消耗一定的内存。
硬件资源：请确认测试环境和生产环境的硬件资源是否一致，尤其是 CPU 核数、内存大小等。不同的硬件配置也可能对 OBProxy 的内存使用产生影响。
内存泄漏：如果排除了上述因素，仍然存在内存占用过高的问题，那么可能存在内存泄漏的情况。您可以尝试使用内存泄漏诊断功能来进一步排查问题。不过需要注意的是，使用内存泄漏诊断功能需要确保 ODP 版本为 V4.2.3 或之后版本，并且需要使用 debug 版本的 obproxy 文件 [2]。
日志分析：您可以查看 OBProxy 的日志文件，特别是关于内存使用的日志信息，以了解具体的内存消耗情况。日志中可能会有关于内存使用情况的详细记录，有助于定位问题。
系统监控：使用系统级别的监控工具（如 top、htop 等）来实时监控 OBProxy 的内存使用情况，可以帮助您更好地理解内存占用的变化趋势。
综上所述，您可以从以下几个方面入手进行排查：
希望这些建议能帮助您解决问题。如果问题仍然存在，请随时提供更多细节，以便进一步分析。
详情请参考:
(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)
麻烦通过如下方式，将第4步获取到的信息发下
本文介绍如何使用内存诊断功能。
ODP 目前记录的内存信息有限，发生内存泄漏后难以快速定位泄露位置。因此，自 ODP V4.2.3 版本起，开发内存泄漏诊断功能帮助解决上述问题。
使用内存泄漏诊断功能前，您需确认以下信息：
obproxy）为 debug 版本文件，您可联系技术支持人员获取。root@sys 用户通过 ODP 代理登录 OceanBase 数据库，或使用 root@proxysys 用户登录 ODP详细操作可参见 配置项说明 中 查看配置项。mem_leak_check_mod_name 配置项，排查内存泄漏问题时推荐配置为 ALL。该配置项的详细介绍可参见 mem_leak_check_mod_name。obclient> alter proxyconfig set mem_leak_check_mod_name=‘ALL’;
设置 mem_leak_check_class_name 配置项，排查内存泄漏问题时推荐配置为空。该配置项的详细介绍可参见 mem_leak_check_class_name。
obclient> alter proxyconfig set mem_leak_check_class_name=’’;
obclient> show proxymemory 3\G
若存在内存分配堆栈，输出如下：
************************** 10. row *************************** mod_name: OB_CONCURRENCY_OBJ_POOL mod_type: user hold: 34,552,064 used: 33,573,536 count: 173 avg_used: 194,066 hold bytes, alloc times and backtraces(addr2line -Cfe obproxy 0xXXXX): 17097232 33 0xf13db9 0xf8994e 0xf85e1b 0xf0973f 0xf25332 0xf26867 0xef75c2 0x10aa1ba 0x10b509a 0x1e71111 0x20ff1a2 0x1e5529d 0x140a655 0xec6ae0 0xec6157 0xec6976 0xec1fa7 0xeaccdf 0xea6201 0xea5ee1 0xea36fc 0xea196e 0xea0dfe 0xe9dbc9 0x20972b1 0x207c559 0x2086a4c 0xf077be 0x7fd3d417c555 0xef6fd5 7176416 14 0xf13db9 0xf8994e 0xf85e1b 0xf0973f 0xf25a75 0xf265f8 0x2281b1e 0x2283de6 0x1dfefee 0x7fd3d55b88e1 0x1e0aed0 0x1e0b73d 0x209e3fa 0x207c546 0x2086a4c 0xf077be 0x7fd3d417c555 0xef6fd5 1319264 22 0xf13db9 0xf8994e 0xf85e1b 0xf0973f 0xf25332 0xf26867 0x10b55fa 0x1e71111 0x20ff1a2 0x1e5529d 0x140a655 0xec6ae0 0xec6157 0xec6976 0xec1fa7 0xeaccdf 0xea6201 0xea5ee1 0xea36fc 0xea196e 0xea0dfe 0xe9dbc9 0x20972b1 0x207c559 0x2086a4c 0xf077be 0x7fd3d417c555 0xef6fd5
[admin@obtest1 bin]$ addr2line -Cfe obproxy 0xf13db9 0xf8994e 0xf85e1b 0xf0973f 0xf25332 0xf26867 0xef75c2 0x10aa1ba 0x10b509a 0x1e71111 0x20ff1a2 0x1e5529d 0x140a655 0xec6ae0 0xec6157 0xec6976 0xec1fa7 0xeaccdf 0xea6201 0xea5ee1 0xea36fc 0xea196e 0xea0dfe 0xe9dbc9 0x20972b1 0x207c559 0x2086a4c 0xf077be 0x7fd3d417c555 0xef6fd5
proxy_mem_limited*80%）后，ODP 会主动打印内存占用最多的 10 条内存记录到 obproxy.log 日志中。您可通过关键字 “MEMORY LEAK CHECK (START)” 查询。proxy_mem_limited*90%）后，ODP 会关闭内存泄漏诊断功能，清理内部保存的内存分配信息，以节省内存。[admin@C20240612221166 bin]$ addr2line -Cfe obproxy 0x1b36ba 0x69e568 0x2131bf 0x1af47f 0x1e0232 0x1db345 0x1a3042 0x2574ba 0x25e42c 0x134ec19 0x13b0652 0x1344905 0x78b8d2 0x85a968 0x78f157 0x85a7ea
oceanbase::common::ObMemLeakChecker::on_alloc(long, char const*, void const*, long)
??:?
oceanbase::lib::ObTenantAllocator::alloc(long, oceanbase::lib::ObMemAttr const&) [clone .localalias]
??:?
oceanbase::lib::ObMallocAllocator::alloc(long, oceanbase::lib::ObMemAttr const&)
??:?
oceanbase::common::ob_malloc_align(long, long, long)
??:?
oceanbase::common::ObObjFreeList::malloc_from_cache(oceanbase::common::ObThreadCache*, long)
??:?
oceanbase::common::ObObjFreeList::alloc()
??:?
oceanbase::common::ObFixedMemAllocator::alloc_void()
??:?
oceanbase::obproxy::event::new_iobufferdata_internal(long)
??:?
oceanbase::obproxy::event::ObMIOBuffer::add_block(long)
??:?
oceanbase::obproxy::ObInternalCmdHandler::init(bool)
??:?
oceanbase::obproxy::obutils::show_memory_cmd_callback(oceanbase::obproxy::event::ObContinuation*, oceanbase::obproxy::ObInternalCmdInfo&, oceanbase::obproxy::event::ObMIOBuffer*, oceanbase::obproxy::event::ObAction*&)
??:?
oceanbase::obproxy::ObInternalCmdProcessor::execute_cmd(oceanbase::obproxy::event::ObContinuation*, oceanbase::obproxy::ObInternalCmdInfo&, oceanbase::obproxy::event::ObMIOBuffer*, oceanbase::obproxy::event::ObAction*&)
??:?
oceanbase::obproxy::proxy::ObMysqlSM::do_internal_request()
??:?
oceanbase::obproxy::proxy::ObMysqlSM::call_transact_and_set_next_state(void (*)(oceanbase::obproxy::proxy::ObMysqlTransact::ObTransState&))
??:?
oceanbase::obproxy::proxy::ObMysqlSM::handle_api_return()
??:?
oceanbase::obproxy::proxy::ObMysqlSM::call_transact_and_set_next_state(void (*)(oceanbase::obproxy::proxy::ObMysqlTransact::ObTransState&))
??:?
obclient> show proxymemory 3\G
这一步也麻烦发下
OB_CONCURRENCY_OBJ_POOL模块hold高，我们联系这块同学分析下
“mod_name”,“mod_type”,“hold”,“used”,“count”,“avg_used”,“hold bytes, alloc times and backtraces(addr2line -Cfe obproxy 0xXXXX)”
“OB_CONCURRENCY_OBJ_POOL”,“user”," 1,413,949,424"," 1,394,847,872"," 3,339"," 417,744","
4259968 8
0x1b36ba 0x69e568 0x2131bf 0x1af47f 0x1e0232 0x1db345 0x1a3042 0x2574ba 0x25e42c 0x134ec19 0x13b0652 0x1344905 0x78b8d2 0x85a968 0x78f157 0x85a7ea
1064992 2
0x1b36ba 0x69e568 0x2131bf 0x1af47f 0x1e0232 0x1db345 0x1a3042 0x2574ba 0x25e42c 0x134ec19 0x13a3684 0x1344905 0x78b8d2 0x85a968 0x78f157 0x85a7ea
24624 3
0x1b36ba 0x69e568 0x2131bf 0x1af47f 0x1e0232 0x1db345 0x25ea8a 0x134ec19 0x13b0652 0x1344905 0x78b8d2 0x85a968 0x78f157 0x85a7ea 0x78d8df 0x7967e4 "
麻烦执行下 show proxymemory objpool 发下
请问老师可以判断出是 obproxy 还是observer 的问题吗？ 如果是obproxy 的问题我们就将版本先降到4.2.3.0-3 .
稍等，还在分析，有进展我尽快回复你
这个是已知问题，不过社区版修复版本还没有发布，可以先回退版本，等发布后再使用新版本
“N9oceanbase7obproxy7obutils20ObLocationTenantInfoE”," 1,192,576,000"," 1,192,159,760"," 123,157"," 9,680"," 0"," 622,592",""
好的, 感谢你的帮助