500租户内存持续增长，glibc_malloc模块占用过高

【 使用环境 】生产环境
【 OB or 其他组件 】observer
【 使用版本 】oceanbase 4.2.3
【问题描述】500租户内存持续增长，glibc_malloc模块占用过高

【复现路径】
1、服务器重启之后，内存逐步增加。应用端会出现“H001,4013,No memory or reach tenant memory limit”
监控数据：

observer占用内存：

2、通过日志收集，

3、日志收集

obdiag_gather_pack_20241119161629.tar.gz (21.6 MB)

【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

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

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

OceanBase 社区已接收您的帖子，正在跟进中。

根据您提供的信息，500 租户内存持续增长，特别是 glibc_malloc 模块占用过高。以下是针对这个问题的分析和建议：

问题分析

1. 内存增长：

   • 从您提供的监控数据和日志来看，500 租户的内存使用量确实在持续增长，并且 glibc_malloc 模块占用较高。
   • 服务器重启后，内存逐步增加，最终导致应用端出现“H001,4013,No memory or reach tenant memory limit”的错误。

2. glibc_malloc 模块占用高：

   • glibc_malloc 模块的内存占用较高，这可能是由于应用程序频繁调用 malloc 和 free 导致的。
   • 从 GV$OB_MEMORY 表的数据来看，glibc_malloc 模块的 hold 和 used 值都非常高。

解决方案

1. 检查内存使用情况：

   • 首先，需要检查系统内存的使用情况，确认是否是系统内存不足导致的问题。
   • 可以使用以下命令查看系统内存使用情况：

     free -m
     

   • 同时，可以查看 observer.log 日志文件，搜索 glibc_malloc 相关的日志信息，进一步分析内存使用情况。

2. 优化内存使用：

   • 如果确定是 glibc_malloc 模块占用过高，可以考虑优化应用程序的内存使用，减少不必要的 malloc 和 free 调用。
   • 可以使用内存分析工具（如 Valgrind）来检测内存泄漏和不合理的内存使用。

3. 调整租户内存配置：

   • 如果内存使用确实超过了租户的限制，可以考虑增加租户的内存配置。
   • 可以通过以下命令查看当前租户的内存配置：

     obclient> SELECT * FROM oceanbase.__all_resource_pool WHERE tenant_id = 500;
     obclient> SELECT * FROM oceanbase.__all_unit_config WHERE unit_config_id IN (SELECT unit_config_id FROM oceanbase.__all_resource_pool WHERE tenant_id = 500);
     

   • 根据实际情况调整租户的内存配置，例如增加 max_memory 参数：

     obclient> ALTER SYSTEM MODIFY RESOURCE UNIT unit_name max_memory = 'new_value';
     

4. 联系技术支持：

   • 如果以上方法无法解决问题，建议联系 OceanBase 的技术支持团队，获取更专业的帮助和指导。

总结

• 检查系统内存使用情况，确认是否是系统内存不足导致的问题。
• 优化应用程序的内存使用，减少不必要的 malloc 和 free 调用。
• 调整租户内存配置，根据实际情况增加租户的内存限制。
• 联系技术支持，获取更专业的帮助和指导。

希望以上建议对您有所帮助。如果您有更多问题或需要进一步的帮助，请随时联系 OceanBase 的技术支持团队。

检索到的文档如下:

1. 内存问题诊断
2. 常见内存问题
3. GV$OB_MEMORY
4. V$OB_MEMORY
5. 内存相关参数
6. 查看内存的使用信息
7. 设置并行执行参数

这个版本是4.2.3，后续会升级至4.2.5，可能那个版本会不会没问题了 ~

根据您提供的信息，您当前使用的 OceanBase 版本是 4.2.3，并且计划升级到 4.2.5。关于 500 租户内存持续增长，特别是 glibc_malloc 模块占用过高的问题，以下是一些建议和可能的解决方案：

升级版本

1. 版本升级：
   • 您提到计划将版本从 4.2.3 升级到 4.2.5。这是一个合理的做法，因为新版本通常会修复一些已知的 bug 和性能问题。
   • 在升级之前，建议您查看 4.2.5 版本的发布说明，了解是否有针对内存管理和 glibc_malloc 模块的改进。
   • 可以参考以下文档来了解如何进行版本升级：
     • OceanBase 升级指南

当前版本的解决方案

1. 检查内存使用情况：

   • 使用 free -m 命令查看系统内存使用情况。
   • 查看 observer.log 日志文件，搜索 glibc_malloc 相关的日志信息，进一步分析内存使用情况。

2. 优化内存使用：

   • 优化应用程序的内存使用，减少不必要的 malloc 和 free 调用。
   • 使用内存分析工具（如 Valgrind）来检测内存泄漏和不合理的内存使用。

3. 调整租户内存配置：

   • 查看当前租户的内存配置：

     obclient> SELECT * FROM oceanbase.__all_resource_pool WHERE tenant_id = 500;
     obclient> SELECT * FROM oceanbase.__all_unit_config WHERE unit_config_id IN (SELECT unit_config_id FROM oceanbase.__all_resource_pool WHERE tenant_id = 500);
     

   • 根据实际情况调整租户的内存配置，例如增加 max_memory 参数：

     obclient> ALTER SYSTEM MODIFY RESOURCE UNIT unit_name max_memory = 'new_value';
     

4. 联系技术支持：

   • 如果以上方法无法解决问题，建议联系 OceanBase 的技术支持团队，获取更专业的帮助和指导。

升级后的验证

1. 升级后验证：

   • 升级到 4.2.5 版本后，继续监控 500 租户的内存使用情况，确保问题得到解决。
   • 使用相同的监控工具和日志分析方法，对比升级前后的内存使用情况。

2. 回滚计划：

   • 在升级前，制定详细的回滚计划，以防升级后问题依然存在或出现新的问题。
   • 保留升级前的备份，以便在必要时快速回滚到旧版本。

总结

• 升级版本：计划将版本从 4.2.3 升级到 4.2.5，查看新版本的发布说明，了解是否有针对内存管理和 glibc_malloc 模块的改进。
• 当前版本的解决方案：检查内存使用情况，优化内存使用，调整租户内存配置，联系技术支持。
• 升级后的验证：升级后继续监控内存使用情况，制定回滚计划。

希望以上建议对您有所帮助。如果您有更多问题或需要进一步的帮助，请随时联系 OceanBase 的技术支持团队。

检索到的文档如下:

1. OceanBase Sysbench 高性能部署和问题分析
2. 4000 ~ 4499
3. 0001 ~ 3999
4. 7000 ~ 7999

(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)

glibc_malloc模块 我看截图仅占用了3G不算高。
select * from __all_virtual_malloc_sample_info where mod_name=‘glibc_malloc’ order by alloc_count desc limit 10; 获取到最大概率发生内存泄漏的内存分配堆栈
有没有考虑过租户扩容

昨晚已经由于内存不足最后重启。目前内存已经恢复正常。
select * from __all_virtual_malloc_sample_info where mod_name=‘glibc_malloc’ order by alloc_count desc limit 10;

另外，服务器目前是64G内存，腾讯云服务器，扩容内存很方便，我们可以扩容服务器内存，进而扩容租户内存；
但是如果，内存就是逐步逐步增加，靠扩容内存好像不是特别好的做法。有时不好定位问题，我们可以尝试其他版本。看老师建议，或者我们可以使用阿里云商业版本的ob，之前这个问题是另外一位老师协助我们定位的，我们也不太想太麻烦老师，能自己解决的尽量自己解决。

老师，应该是这个图片。

这个模块内存应该是占用了40GB

或者，能否看看是否为已经修复的问题，目前使用的4.2.1版本没什么问题。

因为我们看官档确实是有一个“ 腾讯COS 备份长期运行会导致4.2.1.7"自杀" - 社区问答- OceanBase社区-分布式数据库”

421bp8或9都可以

ob可以降级吗？

从现象上看， 腾讯COS 备份长期运行会导致4.2.1.7"自杀" - 社区问答- OceanBase社区-分布式数据库

我觉得我们的情况和这个比较类似。

ob目前不支持降级。目前内存问题复现出来了么

是的

厉害~~~

前来学习~~~

你好如果问题复现出来麻烦抓一下堆栈

例如：addr2line -pCfe /home/admin/oceanbase/bin/observer 0x58b9f0 0x58c00f 0x7fcb153fe61f 0x4a1342 0x9fc8fb 0x9f66f5 0x9dc80e 0x9dd097 0x9dd727 0x9e3fdf 0x9fdcd9 0x9f74eb 0x9e2c1b 0x4abcc0 0x4a801b 0x7fcb144b6444 0x4a1028

目前内存仍然是逐步逐步在涨。

监控数据如下：

但，我考虑 腾讯COS 备份长期运行会导致4.2.1.7"自杀" - 社区问答- OceanBase社区-分布式数据库

这个问题，最近在等12月初的4.2.5.BP1，

select * from __all_virtual_malloc_sample_info where mod_name=‘glibc_malloc’ order by alloc_count desc limit 10; 获取到最大概率发生内存泄漏的内存分配堆栈：

你好问题复现出来麻烦抓一下堆栈，423虽比421bp7发布早，但还不太能确定就是该问题