首批通过分布式安全可靠测评,为关键业务系统打造
MemStore 的 freeze_trigger 低于设定值,导致频繁转储
更新时间:2026-06-12 08:51
适用版本
OceanBase 数据库 V2.x、V3.x 版本。
问题现象
业务租户频繁转储,gv$memstore 视图中显示该租户的 freeze_trigger 远小于 freeze_trigger_percentage * memstore 的值,且不固定。
obclient> SELECT now(),tenant_id, ip, round(active/1024/1024/1024,2) active_gb, round(total/1024/1024/1024,2) total_gb, round(freeze_trigger/1024/1024/1024,2) freeze_trg_gb, round(mem_limit/1024/1024/1024,2) mem_limit_gb, freeze_cnt FROM `gv$memstore` WHERE tenant_id =1002 ORDER BY tenant_id, ip;
返回结果如下。
+---------------------+-----------+-------------+-----------+----------+---------------+--------------+------------+
| now() | tenant_id | ip | active_gb | total_gb | freeze_trg_gb | mem_limit_gb | freeze_cnt |
+---------------------+-----------+-------------+-----------+----------+---------------+--------------+------------+
| 2023-05-17 09:51:55 | 1002 | xx.xx.xx.11 | 1.40 | 1.41 | 22.40 | 32.00 | 0 |
| 2023-05-17 09:51:55 | 1002 | xx.xx.xx.12 | 1.39 | 1.39 | 22.40 | 32.00 | 0 |
| 2023-05-17 09:51:55 | 1002 | xx.xx.xx.13 | 0.19 | 0.19 | 5.84 | 32.00 | 75 |
+---------------------+-----------+-------------+-----------+----------+---------------+--------------+------------+
3 rows in set (0.02 sec)
obclient> SELECT now(),tenant_id, ip, round(active/1024/1024/1024,2) active_gb, round(total/1024/1024/1024,2) total_gb, round(freeze_trigger/1024/1024/1024,2) freeze_trg_gb, round(mem_limit/1024/1024/1024,2) mem_limit_gb, freeze_cnt FROM `gv$memstore` WHERE tenant_id =1002 ORDER BY tenant_id, ip;
返回结果如下。
+---------------------+-----------+-------------+-----------+----------+---------------+--------------+------------+
| now() | tenant_id | ip | active_gb | total_gb | freeze_trg_gb | mem_limit_gb | freeze_cnt |
+---------------------+-----------+-------------+-----------+----------+---------------+--------------+------------+
| 2023-05-17 10:00:08 | 1002 | xx.xx.xx.11 | 1.41 | 1.41 | 22.40 | 32.00 | 0 |
| 2023-05-17 10:00:08 | 1002 | xx.xx.xx.12 | 1.39 | 1.39 | 22.40 | 32.00 | 0 |
| 2023-05-17 10:00:08 | 1002 | xx.xx.xx.13 | 0.19 | 0.19 | 17.15 | 32.00 | 75 |
+---------------------+-----------+-------------+-----------+----------+---------------+--------------+------------+
3 rows in set (0.02 sec)
问题原因
MemStore 的 freeze_trigger 是由 MemStore 的内存上限与配置项 freeze_trigger_percentage 相乘而得,而 MemStore 的内存上限由 MIN(memstore_limit, max_mem_memstore_can_get_now) 计算得到。
memstore_limit = 由租户内存 * memstore_limit_percentage。
max_mem_memstore_can_get_now 是租户实际可以分配给 memstore 的内存上限。如果租户内存使用紧张,max_mem_memstore_can_get_now 可能会远低于 mem_memstore_limit。
MemStore 的实际可分配内存上限可以从 observer.log 的内存统计日志中来查看。
[2023-05-17 11:59:47.547785] INFO [COMMON] ob_tenant_mgr.cpp:611 [23898][0][Y0-0000000000000000-0-0] [lt=6] [dc=0] ====== tenants memstore info ======
[TENANT_MEMSTORE] tenant_id= 1,002 active_memstore_used= 201,235,200 total_memstore_used= 1,052,292,400 total_memstore_hold= 1,054,867,456 minor_freeze_trigger_limit= 825,019,580 memstore_limit= 34,359,738,320 mem_tenant_limit= 42,949,672,960 mem_tenant_hold= 42,855,301,120 mem_memstore_used= 1,054,867,456 kv_cache_mem= 29,360,128 max_mem_memstore_can_get_now= 1,178,599,424
日志信息显示:
memstore_limit= 34,359,738,320。
max_mem_memstore_can_get_now= 1,178,599,424。
minor_freeze_trigger_limit= 825,019,580 = 70% * 1,178,599,424。
实际的 freeze_trigger 只有 800M 左右,所以租户转储频繁。
解决方法
转储频繁是因为租户可以分配给 MemStore 的内存上限过低,租户中存在内存使用紧张的现象。需要分析租户的内存使用,解决导致租户内存紧张的问题。
通过
observer.log日志或者系统视图gv$memory来查看内存使用最高的模块。必要时,抓取 memleak 的信息。
通过
__all_virtual_processlist或gv$sql_audit找到执行异常的 SQL。