【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】
【 使用版本 】4.3.4
【问题描述】清晰明确描述问题
observer的内存一直增加，增大集群的内存，一会就达到90%以上，怎么定位到底是什么在占用内存呢
DEFAULT_CTX_ID的内存为啥一直走高
DEFAULT_CTX_ID的内存为啥一直走高
2 个赞
可以用诊断工具的内存分析看下 obdiag analyze memory
https://www.oceanbase.com/docs/common-obdiag-cn-1000000002968721
1 个赞
参考楼上老师的帮忙获取一份obdiag信息。可以查询下转储是否正常
执行SELECT * FROM oceanbase.GV$OB_TABLET_COMPACTION_HISTORY WHERE TYPE=‘MINI_MERGE’\G
1 个赞
你这个应该是搭建了ocp-express组件，当前该组件不建议使用了，已经不进行维护了。
建议铲掉该组件，或重新搭建个ocp产品
1 个赞
*************************** 28199. row ***************************
SVR_IP: 192.168.0.175
SVR_PORT: 2882
TENANT_ID: 1004
LS_ID: 1001
TABLET_ID: 201609
TYPE: MINI_MERGE
COMPACTION_SCN: 1749023160005666003
START_TIME: 2025-06-04 15:46:04.066689
FINISH_TIME: 2025-06-04 15:46:05.985602
TASK_ID: YB42C0A800AF-0006362900DE7245-0-0
OCCUPY_SIZE: 13900030
MACRO_BLOCK_COUNT: 7
MULTIPLEXED_MACRO_BLOCK_COUNT: 0
NEW_MICRO_COUNT_IN_NEW_MACRO: 971
MULTIPLEXED_MICRO_COUNT_IN_NEW_MACRO: 0
TOTAL_ROW_COUNT: 596330
INCREMENTAL_ROW_COUNT: 596330
COMPRESSION_RATIO: 0.15
NEW_FLUSH_DATA_RATE: 7061
PROGRESSIVE_COMPACTION_ROUND: 0
PROGRESSIVE_COMPACTION_NUM: 0
PARALLEL_DEGREE: 1
PARALLEL_INFO: -
PARTICIPANT_TABLE: table_cnt=1,start_scn=1749017368391477000,end_scn=1749023160005666003;
MACRO_ID_LIST: 78572,78190,78563,78782,78732,78771,78784
COMMENTS: comment=“cost_mb=5;time=add_time:1749023164046248|EXECUTE=1.91s|(1.00)|total=1.92s;”;
START_CG_ID: 0
END_CG_ID: 0
KEPT_SNAPSHOT: {type:“SNAPSHOT_ON_TABLET”, snapshot:1749017368270369000}
MERGE_LEVEL: MACRO_BLOCK_LEVEL
EXEC_MODE: EXEC_MODE_LOCAL
IS_FULL_MERGE: FALSE
IO_COST_TIME_PERCENTAGE: 1
MERGE_REASON:
BASE_MAJOR_STATUS:
CO_MERGE_TYPE:
28199 rows in set (0.644 sec)
内存大和这个组件有关系吗
可以通过gv$ob_memory查一下看看哪个租户内存占比大。ocp-express组件有很久没更新当前已经不进行维护了，所以很多问题都可能会是他或者他的meta租户ocp_meat造成的。再过阵子该组件会下掉不在加入all in one 安装包
1004是业务租户
obclient [oceanbase]> SELECT TENANT_ID,CTX_NAME, MOD_NAME, HOLD, USED FROM oceanbase.GV$OB_MEMORY ORDER BY USED DESC LIMIT 10;
±----------±------------------±----------------±------------±------------+
| TENANT_ID | CTX_NAME | MOD_NAME | HOLD | USED |
±----------±------------------±----------------±------------±------------+
| 1004 | DEFAULT_CTX_ID | IoControl | 15376834560 | 15371571888 |
| 1004 | MEMSTORE_CTX_ID | Memstore | 736591872 | 736254864 |
| 1004 | PLAN_CACHE_CTX_ID | SqlPhyPlan | 694643072 | 647240434 |
| 1004 | DEFAULT_CTX_ID | ArcSendTask | 369733632 | 369604828 |
| 1004 | DEFAULT_CTX_ID | MysqlRequesReco | 366878720 | 366539008 |
| 1 | MEMSTORE_CTX_ID | Memstore | 172703744 | 172624728 |
| 500 | UNEXPECTED_IN_500 | CACHE_MAP_BKT | 134238416 | 134217736 |
| 1004 | META_OBJ_CTX_ID | L_TabletPool | 147456000 | 131182000 |
| 500 | CO_STACK | CoStack | 120766464 | 120541824 |
| 1004 | CO_STACK | CoStack | 119218176 | 118996416 |
±----------±------------------±----------------±------------±------------+
麻烦查下日志
grep ‘1004 ctx_id= DEFAULT_CTX_ID’ observer.log -C 1 -A 10
[root@pdyw log]# ll
total 1476744
drwxr-xr-x. 2 root root 4096 Apr 14 16:39 alert
-rw-r–r-- 1 root root 217185813 Jun 5 10:02 election.log
-rw-r–r–. 1 root root 23937 Jun 4 21:31 election.log.wf
-rw-r–r-- 1 root root 72180186 Jun 5 10:02 observer.log
-rw-r–r-- 1 root root 268435848 Jun 5 09:42 observer.log.20250605094213008
-rw-r–r-- 1 root root 268436214 Jun 5 09:51 observer.log.20250605095116027
-rw-r–r-- 1 root root 268435955 Jun 5 09:59 observer.log.20250605095954149
-rw-r–r–. 1 root root 1924353 Jun 5 09:59 observer.log.wf
-rw-r–r-- 1 root root 108043942 Jun 5 10:02 rootservice.log
-rw-r–r–. 1 root root 108777 Jun 5 08:46 rootservice.log.wf
-rw-r–r-- 1 root root 38907796 Jun 5 10:02 trace.log
-rw-r–r-- 1 root root 268435481 Jun 5 09:45 trace.log.20250605094513106
[root@pdyw log]# grep ‘1004 ctx_id= DEFAULT_CTX_ID’ observer.log* -C 1 -A 10
[root@pdyw log]#
好像没有grep到内容，咱们能帮忙远程看下吗
这个不大好分析啊
好厉害啊
引号换成英文的
就是英文的，我是改成英文的之后，查询的
提供一份详细的observer日志 这边帮忙查看下
可以 如果积分够麻烦您那边提个官方悬赏帖，这边后续使用钉钉进行联系