内存使用率逐步升高，租户出现“HY001, 4013, No memory or reach tenant memory limit“异常

AntTech_ZUHSV7 · 2024 年11 月 5 日 10:36

【使用环境】测试环境
【 OB or 其他组件】oceanbase
【使用版本】4.3.1
【问题描述】
1、我们其他测试环境oceanbase内存是稳定的，但是有一个环境的内存出现逐步升高的情况，
内存监控趋势：

2、是否部分配置不合理引起，实际上我们其他环境未出现类似问题。
【复现路径】内存逐步升高。
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

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

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

论坛小助手 · 2024 年11 月 5 日 10:37

根据您的描述，OceanBase 测试环境中的内存使用率逐步升高，并且出现了 HY001, 4013, No memory or reach tenant memory limit 的异常。这表明租户的内存资源已经达到了上限，可能是由于数据写入量过大、未做限流、或者某些内存模块使用过多等原因导致。

根因分析场景: 内存问题

根因分析命令: obdiag rca run --scene=transaction_other_error

日志采集场景: 内存问题

日志采集命令: obdiag gather scene run --scene=observer.memory

操作步骤：

日志采集：
```
obdiag gather scene run --scene=observer.memory
```
该命令会收集与内存使用相关的日志和信息，包括但不限于内存使用情况、内存分配和回收记录等。
根因分析：
```
obdiag rca run --scene=transaction_other_error
```
该命令会分析事务执行过程中遇到的内存相关错误，帮助确定具体的内存超限原因。

请提供以下信息以便我们更好地帮助您：

当前租户的内存配置：请提供租户的 memory_size 和 memstore_limit 配置。
近期的数据写入情况：是否有大量的数据写入操作？是否有新的业务上线或数据导入？
内存使用监控：是否有监控工具记录了内存使用的变化趋势？如果有，请提供相关图表或数据。
系统日志：是否有其他系统级别的日志（如操作系统日志）显示内存使用异常？
业务场景：当前租户的主要业务场景是什么？是否有特定的业务操作可能导致内存使用激增？

通过以上信息，我们可以更准确地定位问题并提供解决方案。感谢您的配合！

具体信息可参考以下文档:

附上敏捷诊断工具 obdiag 使用帮助链接

淇铭 · 2024 年11 月 5 日 10:54

1、可以根据这个文档排查一下
https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000704208?back=kb
2、把observer.log日志压缩发一下具体分析看看什么问题
3、可以用obdiag分析，上面的小助手的obdiag使用可以参考一下
obdiag gather scene run --scene=observer.memory [options]
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001574123

AntTech_ZUHSV7 · 2024 年11 月 5 日 11:44

老师，我发现，当前日志已经被清空了。

另外，咨询一下，alert.log日志出现以下异常：

论坛小助手 · 2024 年11 月 5 日 11:49

根据您提供的信息，当前日志已经被清空，并且 alert.log 日志中出现了 OB_CLOG_NEW_DISK_SIZE_NOT_ENOUGH 的异常。这些异常提示日志盘的空间不足，无法容纳所有租户的日志。

问题分析

日志盘空间不足：
- alert.log 中的错误信息 OB_CLOG_NEW_DISK_SIZE_NOT_ENOUGH 表明当前日志盘的空间不足，无法满足所有租户的需求。
- 建议的解决方案是增加日志盘的大小，使其大于 336896MB。
日志文件被清空：
- 日志文件被清空可能是由于日志轮转或日志归档策略导致的。OceanBase 默认会进行日志轮转，当日志文件大小达到 256MB 时，系统会进行日志轮转，并生成新的日志文件。
- 如果日志文件被清空，可以检查日志归档配置，确保日志文件不会被频繁删除。

解决步骤

检查日志盘空间：

使用以下 SQL 语句检查日志盘的使用情况：

SELECT tenant_id, svr_ip, svr_port,
       LOG_DISK_IN_USE / 1024 / 1024 / 1024 AS LOG_DISK_IN_USE_G,
       LOG_DISK_SIZE / 1024 / 1024 / 1024 AS LOG_DISK_SIZE_G,
       LOG_DISK_IN_USE * 100 / LOG_DISK_SIZE AS LOG_DISK_USED_PERCENTAGE
FROM GV$OB_UNITS;

增加日志盘空间：
- 如果日志盘空间不足，可以通过以下步骤增加日志盘空间：
  - 修改 log_disk_size 配置项，使其大于 336896MB。
  - 例如，将 log_disk_size 设置为 500GB：
```
ALTER SYSTEM SET log_disk_size = 500G;
```
检查日志归档配置：
- 确保日志归档配置合理，避免日志文件被频繁删除。可以通过以下配置项进行调整：
  - enable_syslog_recycle：是否开启日志回收，默认为 False。
  - max_syslog_file_count：每种日志的最大日志数量，默认为 0。
  - syslog_disk_size：系统日志的磁盘空间上限，默认值为 0M。
  - 例如，设置 max_syslog_file_count 为 1000：
```
ALTER SYSTEM SET max_syslog_file_count = 1000;
```
收集诊断信息：
- 使用 obdiag 工具收集诊断信息，以便进一步分析问题：
```
obdiag gather scene run --scene=observer.memory
```

参考文档

希望以上步骤能帮助您解决问题。如有进一步的问题，请随时联系 OceanBase 的技术支持团队。

详情请参考:

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

AntTech_ZUHSV7 · 2024 年11 月 5 日 12:03

这个命令执行有点小问题，是我没配置好吗？执行其他倒是正常。

observer.log
observer.log (1).tar.gz (19.5 MB)

淇铭 · 2024 年11 月 5 日 13:54

日志清空了就不好查了日志设置的空间不够 log_disk_size这个参数设置的过小了是内存memory_limit的三到四倍
你查一下这几个参数
show parameters where name in (‘memory_limit’,‘memory_limit_percentage’,‘system_memory’,‘log_disk_size’,‘log_disk_percentage’,‘datafile_size’,‘datafile_disk_percentage’,‘max_syslog_file_count’);

淇铭 · 2024 年11 月 5 日 13:56

看着是没有权限写入这个文件夹下

AntTech_ZUHSV7 · 2024 年11 月 5 日 16:21

老师，你好，
执行”show parameters where name in (‘memory_limit’,‘memory_limit_percentage’,‘system_memory’,‘log_disk_size’,‘log_disk_percentage’,‘datafile_size’,‘datafile_disk_percentage’,‘max_syslog_file_count’);“ 结果如下：

后面我们此前已经增加过log_disk_size，好像没体现在参数上，实际情况如下：

AntTech_ZUHSV7 · 2024 年11 月 5 日 16:25

另外，老师，请问执行：obdiag gather scene run --scene=observer.memory

失败的原因是什么没配置好吗？

淇铭 · 2024 年11 月 5 日 16:31

我楼上回复你了看着是/tmp这个文件夹没有权限写入

淇铭 · 2024 年11 月 5 日 16:34

我看你设置了这个参数 memory_limit_percentage 你的物理内存看一下 cat /proc/meminfo

AntTech_ZUHSV7 · 2024 年11 月 5 日 16:36

噢噢，不好意思，但是，这样稍微有点点奇怪。

/tmp的权限应该没问题。

重新授权发现还是有点问题。

AntTech_ZUHSV7 · 2024 年11 月 5 日 16:38

老师，麻烦看看。

[root@test clog]# cat /proc/meminfo
MemTotal: 64127084 kB
MemFree: 16916928 kB
MemAvailable: 24322168 kB
Buffers: 99732 kB
Cached: 13114756 kB
SwapCached: 0 kB
Active: 3176388 kB
Inactive: 43103204 kB
Active(anon): 497200 kB
Inactive(anon): 32570044 kB
Active(file): 2679188 kB
Inactive(file): 10533160 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 22252 kB
Writeback: 0 kB
AnonPages: 32430924 kB
Mapped: 448020 kB
Shmem: 2040 kB
KReclaimable: 432364 kB
Slab: 620664 kB
SReclaimable: 432364 kB
SUnreclaim: 188300 kB
KernelStack: 32752 kB
PageTables: 77176 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 32063540 kB
Committed_AS: 35561780 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 153736 kB
VmallocChunk: 0 kB
Percpu: 4480 kB
HardwareCorrupted: 0 kB
AnonHugePages: 30924800 kB
ShmemHugePages: 0 kB
ShmemPmdMapped: 0 kB
FileHugePages: 0 kB
FilePmdMapped: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
Hugetlb: 0 kB
DirectMap4k: 671584 kB
DirectMap2M: 43368448 kB
DirectMap1G: 24117248 kB