Step 1: 确认 500 租户下占用内存较多的模块，通过 OceanBase 的系统视图可以获取。
select * from __all_virtual_memory_info where tenant_id = 500 order by used desc limit 1;
⚠️ 注意：
其中的 label 字段，后面会用到。
Step 2：收集内存模块的信息。
为了便于排查内存泄露问题，OceanBase 数据库实现了内存泄露动态诊断功能，其工作原理是在每一次跟踪模块进行内存分配的时候，记录其申请内存的地址及相应的调用栈；在所申请内存被释放的时候，将该条记录清空。
这样正常申请、释放内存的调用栈会被很快清空，而出现内存泄露的调用栈的记录将一直存在，最后再按照调用栈进行分组，将每个不同的调用栈当前存在的申请记录进行累加，显示在虚拟表 __all_mem_leak_checker_info 中。
换言之，累计次数多的调用栈很可能出现了内存泄露。当然也有可能是由于各种缓存而造成的，这个需要具体问题具体分析。
采集方法：
alter system set leak_mod_to_check='CO_STACK'; （ob 3.x）开启该内存模块监控：
alter system set leak_mod_to_check='CO_STACK@tenant_id'; （ob 4.x）⚠️ 注意：
开启该内存模块监控一定要等待一段时间，观察到 CO_STACK 持续增长较大量之后再去执行后面的动作。
select * from __all_virtual_memory_info where tenant_id=500 and svr_ip='xx.xx.xx.xx' and mod_name='CO_STACK' ;select * from __all_virtual_mem_leak_checker_info order by alloc_size desc limit 10;
Step 3：查看相关泄漏栈信息。
分别对 alloc_size alloc_cnt 降序排列取前三条；时间不固定，主要条件是 CO_STACK 模块要在这个时间窗口内有较大的增长，比如 500M，然后用 addr2line -pCfe ./bin/observer 命令配合 back_trace 泄露栈的十六进制数据查看具体的泄露信息。
上面这种诊断方式是数据库原厂做诊断分析常用的方式，基于数据库提供的基础 TRACE 能力进行分析。这种方法适合于发现数据库产品的 BUG 导致的问题。
想要很好地运用这种方法，必须在数据库原厂工程师的配合下才可以很好地完成。否则哪怕发现了问题，也无法定位问题。对于普通用户的日常问题定位来说，不一定随时有效。
另外一个方法是基于运维知识。将 500 内存可能引发的问题梳理清楚，并构建成一个知识图谱。
当第一步的模块被确认后，可以通过知识图谱梳理出来的诊断路径进行分析。如果确认是某条路径引发的问题，就可以立即定位问题。
不过在很多情况下，问题可能没有出现在这张图里，这时候就需要利用一些泛化推理的模型去做非精准的分析。利用运维知识图谱或者大语言模型的泛化推理能力是目前可以使用的两种常用方法。
如果企业已经构建了基于 OceanBase 的运维知识图谱，那么利用图谱的临近发现和关联发现的算法，可以找到一些相似的问题分析路径，从而大致推理出可能的 RCA。
当然也有可能泛化分析还是无法找到根因，这时候就只能借助上述的第一种方式去分析，一旦定位了根因，那么这个新的知识可以添加到运维知识图谱中，不断完善运维知识图谱。
运维平台采集的历史数据
要想实现分析，不仅仅依赖于上述两种方法，如果故障发生时并没有 DBA 在现场，那么我们还需要依赖运维平台采集的历史数据。
因此在平时我们需要对 500 内存中主要模块的使用情况进行分析。D-SMART 目前已经采集了 TOP 10 的 500 内存以及经常会出现问题的模块的使用信息。利用平台提供的比对工具可以对当前曲线与前些天的曲线进行比较。最重要的是，有了历史数据，自动分析工具就能根据运维知识图谱的诊断路径自动进行问题分析，自动发现可能存在的问题。
