--- title: 公有云 MemStore 内存释放问题分析与解决-OceanBase数据库使用指南 description: 了解OceanBase数据库在实际应用中关于 公有云 MemStore 内存释放问题分析与解决相关的常见问题和使用技巧，帮助您快速解决 公有云 MemStore 内存释放问题分析与解决的难题。 --- 切换语言 - 简体中文 - English 划线反馈 # 公有云 MemStore 内存释放问题分析与解决 更新时间：2026-05-08 08:11 适用版本： V4.3.x 内容类型：Troubleshoot ## 问题现象 MemTable 已经转储成功，但是长时间未能被释放，导致内存占用持续增加。列存合并结束或重启后，MemTable 被释放，内存占用下降。 ## 关键诊断信息 ### 触发条件 列存合并触发 Minor，条件如下： 1. 列存合并时，表的 column group 数量大于 20。 2. 合并选中的 Mini SSTable 数量超过 3 个。 3. 合并选中的大于 10 万行的 Mini SSTable 至少有一个。 ### 事前巡检 1. 检查系统配置，确认 `_enable_adaptive_merge_schedule` 参数是否已关闭，以避免触发可能导致 MemTable 长时间不释放的 Minor 合并路径。 2. 监控 MemTable 的创建和释放时间，特别是对于那些长时间未被释放的 MemTable。 ### 事后诊断 查看日志，确认是否存在 MemTable 长时间未被释放的情况。搜索 `It cost too much time to dec ref cnt` 日志，解出 lbt 看是否是列存合并释放的 MemTable。 ```shell [2025-07-17 12:54:25.301247] WDIAG [STORAGE] push_table_into_gc_queue (ob_tenant_meta_mem_mgr.cpp:471) [683437][T1002_DagSchedu][T1002][Y0-0000000000000000-0-0] [lt=23][errcode=0] It cost too much time to dec ref cnt(ret=0, memtable={ObITabletMemtable:{ObITable:{this:0x7f2596ec80c0, key:{tablet_id:{id:12515603}, column_group_idx:0, slice_range:{start_slice_idx:0, end_slice_idx:0}, table_type:"MEMTABLE", scn_range:{start_scn:{val:1752727388197677001, v:0}, end_scn:{val:1752727588103463001, v:0}}}, ref_cnt:0, upper_trans_version:9223372036854775807, timestamp:1752727388213731}, ls_id_:{id:25466}, allow_freeze_:true, is_flushed_:true, is_tablet_freeze_:false, logging_blocked_:false, resolved_active_memtable_left_boundary_:true, unset_active_memtable_logging_blocked_:false, has_backoffed_:false, offlined_:false, read_barrier_:true, freeze_clock_:15, freeze_state_:5, unsubmitted_cnt_:0, init_timestamp_:1752727388213731, max_schema_version_:0, write_ref_cnt_:0, max_end_scn_:{val:1752727588103463001, v:0}, rec_scn_:{val:1752727388201892001, v:0}, freeze_scn_:{val:1752727588103463001, v:0}, freezer_:0x7f6d86615490, memtable_mgr_handle_:{memtable_mgr:0x7f6d8459b590, pool:0x7f6dafeea030}, mt_stat_.frozen_time_:1752727588110169, mt_stat_.ready_for_flush_time_:1752727588111838, mt_stat_.create_flush_dag_time_:1752727620192271, mt_stat_.release_time_:1752727712507165, mt_stat_.push_table_into_gc_queue_time_:1752728065301195, mt_stat_.last_print_time_:0}, this:0x7f2596ec80c0, state:0, max_data_schema_version:1752722701315808, max_column_cnt:119, local_allocator:{ListHandle:{freeze_stat:2, id:2548, clock:457892167680}, host:0x7f6db72822b0, arena_handle:{allocated:10127147008}}, contain_hotspot_row:false, snapshot_version:{val:1752727588034308001, v:0}, contain_hotspot_row:false, ls_id:{id:25466}, transfer_freeze_flag:false, recommend_snapshot_version:{val:18446744073709551615, v:3}, is_delete_insert_table:false}, lbt()="0x28de404d 0x1eb8546a 0x1eb84a7c 0x1cd06e35 0x1eb5ceae 0xa00acda 0x1cddf46a 0x1e5512e2 0x1e545bf5 0x203a4a6d 0x28dd5045 0x28dd3152 0x7f6e747a33fb 0x7f6e745fbe83") ``` 如果是列存合并释放的 MemTable 则大概率是该问题。 为进一步核验，可以搜索 `CO_MERGE` 关键字查看列存合并相关日志，查看是否有触发了 Minor 的记录。如有以下信息说明该列存合并走了 Minor 路径，然后通过 trace id 找到该列存合并对应的 tablet_id，再去核对 `It cost too much time to dec ref cnt` 日志中打印的 tablet_id 是否有相匹配的。（由于日志限流以及 tablet_id 打印数量的影响，有可能会找不到匹配项）。 ```shell [2025-07-17 12:47:02.221355] INFO [COMMON] inner_add_dag_ (ob_tenant_dag_scheduler.cpp:2125) [685697][T1002_CO_MERGE_][T1002][xxxxx-xxxxx-xxxxx-xxxxx] [lt=22] add dag success(dag=0x7f42d01acf60, id=Y0-0000000000000000-0-0, dag->hash()=6135514763398756329, dag_cnt=4, dag_type="CO_MERGE_SCHEDULE", dag_type_cnts=1) [2025-07-17 12:47:02.221366] INFO [COMMON] inner_add_dag_ (ob_tenant_dag_scheduler.cpp:2125) [685697][T1002_CO_MERGE_][T1002][xxxxx-xxxxx-xxxxx-xxxxx] [lt=7] add dag success(dag=0x7f42d01ac030, id=Y0-0000000000000000-0-0, dag->hash()=4818155980350475306, dag_cnt=5, dag_type="MINOR_EXECUTE", dag_type_cnts=1) ``` ## 问题原因 列存合并过程中，即使最初获取的是不包含 MemTable 的 tablet（有关该修复的详情参见：[由于列存合并执行时间长导致 MemTable 内存释放慢](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000002045008?back=kb)），当需要额外调度 Minor 合并时，由于重新交换了一次 tablet，会再次取到包含 MemTable 的 tablet。 由于列存合并时间通常较长，这会导致 MemTable 长时间无法释放，进而引发内存不释放的问题。 ## 问题的风险及影响 MemTable 释放慢，可能导致内存占用持续增加，影响数据库性能。 打开 `_enable_adaptive_merge_schedule` 参数主要影响以下几个方面： 1. 列存合并将根据租户内存和合并线程数自动调整单个任务处理 column group 的数量。 2. 列存合并会在满足条件时触发 Minor。 3. 根据内存/CPU 调整转储/合并的并发度，多用于降载。 4. 动态调整转储 DAG 队列中 DAG 的顺序。 ## 影响租户 影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。 ## 影响版本 OceanBase 数据库企业版 V4.3.5 GA（oceanbase-4.3.5.0-100000122024123020）及之后版本。 ## 解决方法 - 升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V4.3.5 BP2 Hotfix7（oceanbase-4.3.5.2-102070022025081416）、V4.3.5 BP2 Hotfix8（oceanbase-4.3.5.2-102080022025082111）、V4.3.5 BP2 Hotfix9（oceanbase-4.3.5.2-102090012025082611）、V4.3.5 BP4（oceanbase-4.3.5.4-104000052025090918）及之后版本。 - 加内存或重启。 ## 规避方式 1. 在不影响业务的情况下，提前关闭 `_enable_adaptive_merge_schedule` 参数，防止在列存合并过程中触发额外的 Minor 合并。 2. 定期监控 MemTable 的状态，一旦发现有 MemTable 长时间未被释放，及时采取措施，如重启 OBServer 等。 Previous [Nest Loop Join 场景查询内存膨胀问题](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000001489345) Next [ODP 内存监控告警与自重启机制](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000209943) ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线