内存泄漏是指OB的某个租户内的某个内存模块占用内存过大，排查内存泄漏问题需要明确如下2个思路：
1，到底有没有发生泄漏：如果某个租户的某个内存模块的内存占用非常大，但是没有任何人干预的情况下，这个内存模块的内存自行降低，这是泄漏吗？一般我们不认为这是泄漏，某个内存模块使用的内存增加但是能自动恢复一般说明是某些行为导致了内存的增加，这些行为结束后，内存可以成功释放，不是泄漏，泄漏是指即使这些行为结束，内存模块的内存占用依然居高不下（有时会一直增加不会下降），这种一般才是泄漏
2，发生泄漏如何排查：明确某个内存模块发生泄漏后，按照如下文档进行内存泄漏的堆栈的抓取和排查：
《使用OB Memory Leaker诊断OB内存模块问题》
使用该方法抓取内存泄漏堆栈，需要明确如下几点：
1，在memleak的抓取开启期间，内存模块是否处于继续增长的状态，如果在抓取memleak期间，异常的内存模块内存大小无明显变化，则抓取不成功
抓取memleak会略微影响ob的性能，但是感知不明显，需要和甲方进行说明。
2，内存泄漏为什么要抓堆栈？
3，抓了堆栈之后，就能定位泄漏原因了吗？
4，如果是sql导致内存泄漏，如何定位造成内存泄漏的sql呢？
《使用OB Memory Leaker诊断OB内存模块问题》
发生原因
由于OBServer内核的原因，导致OBServer的某一个模块(Mod)的内存消耗持续增长，内存增长的情况可以通过OB的虚表__all_virtual_memory_info监控到。从现象上怀疑这个模块有内存泄露的情况，需要进一步理解和诊断OB内核的哪一部分代码路径在分配内存，分析是否符合预期。
解决办法：
1. 通过__all_virtual_memory_info 找到内存不断增长的模块，并将模块的名字记录成mod1；
2. 通过alter system set leak_mod_to_check='mod1' 开启mod模块的内存分配监控。比如说想要捕获libeasy context中OB_TEST2_PCODE 模块的内存的代码路径，可以用一下SQL进行开启：
过alter system set leak_mod_to_check='OB_TEST2_PCODE'
3. 重现问题（必须重建问题后停止抓取memleak，不然抓取无效），监控mod1的内存使用（通过observer.log 或者__all_virtual_memory_info), 观察到问题重现，mod1内存一直上涨；
4. select * from __all_virtual_mem_leak_checker_info order by alloc_count; 有内容后将结果保留成文本格式；
5. 在开启内存监控追踪功能后发现目标模块mod1内存增长， 且步骤4可以看到该模块的内存分配代码路径（为地址hex值，这意味着已经捕捉到了内存增长（泄露）的凶手，此时可以通过SQL将内存分配监控停下来： alter system set leak_mod_to_check= ''；
6. 将步骤3中的back_trace字段内容拷贝出来，尝试用 addr2line -pCfe $observer $back_trace打印出来栈信息： 例如
addr2line -pCfe /home/admin/oceanbase/bin/observer $back_trace
7. 将步骤3，4，6步骤中的内容发回来OB技术支持进行分析诊断。
---- 以上内容来自某大神笔记，如有侵权，请联系删除
标签：泄漏,OceanBase,抓取,OB,内存,模块,内存模块 From： https://www.cnblogs.com/bayaim/p/18375478