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..68bca995a2b960cda0d1401b7ea4d1b9cc10ce31 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
 
@@ -12,12 +12,12 @@
 obclient> alter system set leak_mod_to_check='OB_COMMON_ARRAY';
 ```
 
-像这样，就指定了跟踪模块为 OB_COMMON_ARRAY，设置完毕后就可以开始监控 `__all_virtual_mem_leak_checker_info` 表的信息，查看可能出问题的调用栈。
+像这样，就指定了跟踪模块为 OB_COMMON_ARRAY，设置完毕后就可以开始监控 `__all_virtual_memory_leak_checker_info` 表的信息，查看可能出问题的调用栈。
 
 ### 查询
 
 ```sql
-obclient> select * from __all_virtual_mem_leak_checker_info order by alloc_count desc;
+obclient> select * from __all_virtual_memory_leak_checker_info order by alloc_count desc;
 ```
 
 一般来说存在泄露的调用栈计数都很大（而且越来越大），将这样的调用栈利用 addr2line 打印出。