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

AntTech_ZUHSV7 · 2024 年11 月 19 日 18:03

【使用环境】生产环境
【 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 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

辞霜 · 2024 年11 月 19 日 18:04

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

论坛小助手 · 2024 年11 月 19 日 18:09

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

问题分析

内存增长：
- 从您提供的监控数据和日志来看，500 租户的内存使用量确实在持续增长，并且 glibc_malloc 模块占用较高。
- 服务器重启后，内存逐步增加，最终导致应用端出现“H001,4013,No memory or reach tenant memory limit”的错误。
glibc_malloc 模块占用高：
- glibc_malloc 模块的内存占用较高，这可能是由于应用程序频繁调用 malloc 和 free 导致的。
- 从 GV$OB_MEMORY 表的数据来看，glibc_malloc 模块的 hold 和 used 值都非常高。

解决方案

检查内存使用情况：
- 首先，需要检查系统内存的使用情况，确认是否是系统内存不足导致的问题。
- 可以使用以下命令查看系统内存使用情况：
```
free -m
```
- 同时，可以查看 observer.log 日志文件，搜索 glibc_malloc 相关的日志信息，进一步分析内存使用情况。
优化内存使用：
- 如果确定是 glibc_malloc 模块占用过高，可以考虑优化应用程序的内存使用，减少不必要的 malloc 和 free 调用。
- 可以使用内存分析工具（如 Valgrind）来检测内存泄漏和不合理的内存使用。

调整租户内存配置：

如果内存使用确实超过了租户的限制，可以考虑增加租户的内存配置。

可以通过以下命令查看当前租户的内存配置：

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';

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

总结

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

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

检索到的文档如下:

AntTech_ZUHSV7 · 2024 年11 月 20 日 09:09

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

论坛小助手 · 2024 年11 月 20 日 09:17

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

升级版本

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

当前版本的解决方案

检查内存使用情况：
- 使用 free -m 命令查看系统内存使用情况。
- 查看 observer.log 日志文件，搜索 glibc_malloc 相关的日志信息，进一步分析内存使用情况。
优化内存使用：
- 优化应用程序的内存使用，减少不必要的 malloc 和 free 调用。
- 使用内存分析工具（如 Valgrind）来检测内存泄漏和不合理的内存使用。

调整租户内存配置：

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

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';

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

升级后的验证

升级后验证：
- 升级到 4.2.5 版本后，继续监控 500 租户的内存使用情况，确保问题得到解决。
- 使用相同的监控工具和日志分析方法，对比升级前后的内存使用情况。
回滚计划：
- 在升级前，制定详细的回滚计划，以防升级后问题依然存在或出现新的问题。
- 保留升级前的备份，以便在必要时快速回滚到旧版本。

总结

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

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

检索到的文档如下:

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

辞霜 · 2024 年11 月 20 日 10:08

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

AntTech_ZUHSV7 · 2024 年11 月 20 日 12:08

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

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