diff --git a/zh-CN/15.oceanbase-database-overview/14.observer-architecture/5.oceanbase-database-overview-memory-management/5.memory-related-problem-diagnosis.md b/zh-CN/15.oceanbase-database-overview/14.observer-architecture/5.oceanbase-database-overview-memory-management/5.memory-related-problem-diagnosis.md
index d0486555ae620ee6fb6e39569ac36a8a5419ba7b..eb95791d8e8c016863e9b72163895bbcdd0a3ca0 100644
--- a/zh-CN/15.oceanbase-database-overview/14.observer-architecture/5.oceanbase-database-overview-memory-management/5.memory-related-problem-diagnosis.md
+++ b/zh-CN/15.oceanbase-database-overview/14.observer-architecture/5.oceanbase-database-overview-memory-management/5.memory-related-problem-diagnosis.md
@@ -4,7 +4,7 @@
 
 `__all_virtual_memory_info` 显示了整个 OBServer 通过 ObMalloc 分配内存的情况，每一块内存都有一个标签叫做 label 或者 mod_id，通过查看 mod 的统计信息，可以分析系统内存的使用情况，并初步确认疑似存在内存泄露的模块。
 
-为了便于排查内存泄露问题，OceanBase 数据库实现了内存泄漏动态诊断机制，其工作原理是在每一次跟踪模块进行内存分配的时候，记录其申请内存的地址及相应的调用栈；在所申请内存被释放的时候，将该条记录清空。这样正常申请、释放内存的调用栈会被很快清空，而出现内存泄露的调用栈的记录将一直存在，最后我们按照调用栈进行分组，将每个不同的调用栈当前存在的申请记录进行累加，显示在 `__all_virtual_mem_leak_checker_info` 中。换言之，累计次数多的调用栈很可能出现了内存泄露（当然也有可能是由于各种缓存而造成的，这个需要具体问题具体分析）。
+为了便于排查内存泄露问题，OceanBase 数据库实现了内存泄漏动态诊断机制，其工作原理是在每一次跟踪模块进行内存分配的时候，记录其申请内存的地址及相应的调用栈；在所申请内存被释放的时候，将该条记录清空。这样正常申请、释放内存的调用栈会被很快清空，而出现内存泄露的调用栈的记录将一直存在，最后我们按照调用栈进行分组，将每个不同的调用栈当前存在的申请记录进行累加，显示在 `__all_virtual_memory_leak_checker_info` 中。换言之，累计次数多的调用栈很可能出现了内存泄露（当然也有可能是由于各种缓存而造成的，这个需要具体问题具体分析）。
 
 ### 打开 memory_leak