diff --git a/docs/documentation/cn/developer-guide/debug-tool.md b/docs/documentation/cn/developer-guide/debug-tool.md
new file mode 100644
index 0000000000..5be5582975
--- /dev/null
+++ b/docs/documentation/cn/developer-guide/debug-tool.md
@@ -0,0 +1,247 @@
+# 调试工具
+
+在Doris的使用、开发过程中,经常会遇到需要对Doris进行调试的场景,这里介绍一些常用的调试工具。
+
+## 环境准备
+
+[pprof](https://github.com/google/pprof): 来自gperftools,用于将gperftools所产生的内容转化成便于人可以阅读的格式,比如pdf, svg, text等.
+
+[graphviz](http://www.graphviz.org/): 在没有这个库的时候pprof只可以转化为text格式,但这种方式不易查看。那么安装这个库后,pprof可以转化为svg、pdf等格式,对于调用关系则更加清晰明了。
+
+[perf](https://perf.wiki.kernel.org/index.php/Main_Page): linux内核自带性能分析工具。[这里](http://www.brendangregg.com/perf.html)有一些perf的使用例子。
+
+[FlameGraph](https://github.com/brendangregg/FlameGraph): 可视化工具,用于将perf的输出以火焰图的形式展示出来。
+
+## 内存
+
+对于内存的调试一般分为两个方面。一个是内存使用的总量是否合理,内存使用量过大一方面可能是由于系统存在内存泄露,另一方面可能是因为程序内存使用不当。其次就是是否存在内存越界、非法访问的问题,比如程序访问一个非法地址的内存,使用了未初始化内存等。对于内存方面的调试我们一般使用如下几种方式来进行问题追踪。
+
+### 查看日志
+
+当发现内存使用量过大的时候,我们可以先查看be.out日志,看看是否有大内存申请。由于Doris当前使用的TCMalloc管理内存,那么遇到大内存申请时,都会将申请的堆栈打印到be.out文件中,一般的表现形式如下:
+
+```
+tcmalloc: large alloc 1396277248 bytes == 0x3f3488000 @ 0x2af6f63 0x2c4095b 0x134d278 0x134bdcb 0x133d105 0x133d1d0 0x19930ed
+```
+
+这个表示在Doris BE在这个堆栈上尝试申请`1396277248 bytes`的内存。我们可以通过`addr2line`命令去把堆栈还原成我们能够看懂的信,具体的例子如下所示。
+
+```
+$ addr2line -e lib/palo_be 0x2af6f63 0x2c4095b 0x134d278 0x134bdcb 0x133d105 0x133d1d0 0x19930ed
+
+/home/ssd0/zc/palo/doris/core/thirdparty/src/gperftools-gperftools-2.7/src/tcmalloc.cc:1335
+/home/ssd0/zc/palo/doris/core/thirdparty/src/gperftools-gperftools-2.7/src/tcmalloc.cc:1357
+/home/disk0/baidu-doris/baidu/bdg/doris-baidu/core/be/src/exec/hash_table.cpp:267
+/home/disk0/baidu-doris/baidu/bdg/doris-baidu/core/be/src/exec/hash_table.hpp:86
+/home/disk0/baidu-doris/baidu/bdg/doris-baidu/core/be/src/exec/hash_join_node.cpp:239
+/home/disk0/baidu-doris/baidu/bdg/doris-baidu/core/be/src/exec/hash_join_node.cpp:213
+thread.cpp:?
+```
+
+### HEAP PROFILE
+
+有时内存的申请并不是大内存的申请导致,而是通过小内存不断的堆积导致的。那么就没有办法通过查看日志定位到具体的申请信息,那么就需要通过其他方式来获得信息。
+
+这个时候我们可以利用TCMalloc的[HEAPPROFILE](https://gperftools.github.io/gperftools/heapprofile.html)的功能。如果设置了HEAPPROFILE功能,那么我们可以获得进程整体的内存申请使用情况。使用方式是在启动Doris BE前设置`HEAPPROFILE`环境变量。比如:
+
+```
+export HEAPPROFILE=/tmp/doris_be.hprof
+./bin/start_be.sh --daemon
+```
+
+这样,当满足HEAPPROFILE的dump条件时,就会将内存的整体使用情况写到指定路径的文件中。后续我们就可以通过使用`pprof`工具来对输出的内容进行分析。
+
+```
+$ pprof --text lib/palo_be /tmp/doris_be.hprof.0012.heap | head -30
+
+Using local file lib/palo_be.
+Using local file /tmp/doris_be.hprof.0012.heap.
+Total: 668.6 MB
+ 610.6 91.3% 91.3% 610.6 91.3% doris::SystemAllocator::allocate_via_malloc (inline)
+ 18.1 2.7% 94.0% 18.1 2.7% _objalloc_alloc
+ 5.6 0.8% 94.9% 63.4 9.5% doris::RowBatch::RowBatch
+ 5.1 0.8% 95.6% 7.1 1.1% butil::ResourcePool::add_block (inline)
+ 3.7 0.5% 96.2% 3.7 0.5% butil::iobuf::create_block (inline)
+ 3.4 0.5% 96.7% 3.4 0.5% butil::FlatMap::init
+ 3.2 0.5% 97.2% 5.2 0.8% butil::ObjectPool::add_block (inline)
+ 2.6 0.4% 97.6% 2.6 0.4% __gnu_cxx::new_allocator::allocate (inline)
+ 2.0 0.3% 97.9% 2.0 0.3% butil::ObjectPool::add_block_group (inline)
+ 2.0 0.3% 98.2% 2.0 0.3% butil::ResourcePool::add_block_group (inline)
+ 1.7 0.3% 98.4% 1.7 0.3% doris::SegmentReader::_load_index
+```
+
+上述文件各个列的内容:
+
+* 第一列:函数直接申请的内存大小,单位MB
+* 第四列:函数以及函数所有调用的函数总共内存大小。
+* 第二列、第五列分别是第一列与第四列的的比例值。
+* 第三列是个第二列的累积值。
+
+当然也可以生成调用关系图片,更加方便分析。比如下面的命令就能够生成SVG格式的调用关系图。
+
+```
+pprof --svg lib/palo_be /tmp/doris_be.hprof.0012.heap > heap.svg
+```
+
+**注意:开启这个选项是要影响程序的执行性能的,请慎重对线上的实例开启**
+
+### pprof remote server
+
+HEAPPROFILE虽然能够获得全部的内存使用信息,但是也有比较受限的地方。1. 需要重启BE进行。2. 需要一直开启这个命令,导致对整个进程的性能造成影响。
+
+对Doris BE也可以使用动态开启、关闭heap profile的方式来对进程进行内存申请分析。Doris内部支持了GPerftools的[远程server调试](https://gperftools.github.io/gperftools/pprof_remote_servers.html)。那么可以通过`pprof`直接对远程运行的Doris BE进行动态的HEAP PROFILE。比如我们可以通过以下命令来查看Doris的内存的使用增量
+
+```
+$ pprof --text --seconds=60 http://be_host:be_webport/pprof/heap
+
+Total: 1296.4 MB
+ 484.9 37.4% 37.4% 484.9 37.4% doris::StorageByteBuffer::create
+ 272.2 21.0% 58.4% 273.3 21.1% doris::RowBlock::init
+ 157.5 12.1% 70.5% 157.5 12.1% doris::RowBatch::RowBatch
+ 90.7 7.0% 77.5% 90.7 7.0% doris::SystemAllocator::allocate_via_malloc
+ 66.6 5.1% 82.7% 66.6 5.1% doris::IntegerColumnReader::init
+ 47.9 3.7% 86.4% 47.9 3.7% __gnu_cxx::new_allocator::allocate
+ 20.8 1.6% 88.0% 35.4 2.7% doris::SegmentReader::_load_index
+ 12.7 1.0% 89.0% 12.7 1.0% doris::DecimalColumnReader::init
+ 12.7 1.0% 89.9% 12.7 1.0% doris::LargeIntColumnReader::init
+ 12.7 1.0% 90.9% 12.7 1.0% doris::StringColumnDirectReader::init
+ 12.3 0.9% 91.9% 12.3 0.9% std::__cxx11::basic_string::_M_mutate
+ 10.4 0.8% 92.7% 10.4 0.8% doris::VectorizedRowBatch::VectorizedRowBatch
+ 10.0 0.8% 93.4% 10.0 0.8% doris::PlainTextLineReader::PlainTextLineReader
+```
+
+这个命令的输出与HEAP PROFILE的输出及查看方式一样,这里就不再详细说明。这个命令只有在执行的过程中才会开启统计,相比HEAP PROFILE对于进程性能的影响有限。
+
+### LSAN
+
+[LSAN](https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer)是一个地址检查工具,GCC已经集成。在我们编译代码的时候开启相应的编译选项,就能够开启这个功能。当程序发生可以确定的内存泄露时,会将泄露堆栈打印。Doris BE已经集成了这个工具,只需要在编译的时候使用如下的命令进行编译就能够生成带有内存泄露检测版本的BE二进制
+
+```
+BUILD_TYPE=LSAN ./build.sh
+```
+
+当系统检测到内存泄露的时候,就会在be.out里面输出对应的信息。为了下面的演示,我们故意在代码中插入一段内存泄露代码。我们在`StorageEngine`的`open`函数中插入如下代码
+
+```
+ char* leak_buf = new char[1024];
+ strcpy(leak_buf, "hello world");
+ LOG(INFO) << leak_buf;
+```
+
+我们就在be.out中获得了如下的输出
+
+```
+=================================================================
+==24732==ERROR: LeakSanitizer: detected memory leaks
+
+Direct leak of 1024 byte(s) in 1 object(s) allocated from:
+ #0 0xd10586 in operator new[](unsigned long) ../../../../gcc-7.3.0/libsanitizer/lsan/lsan_interceptors.cc:164
+ #1 0xe333a2 in doris::StorageEngine::open(doris::EngineOptions const&, doris::StorageEngine**) /home/ssd0/zc/palo/doris/core/be/src/olap/storage_engine.cpp:104
+ #2 0xd3cc96 in main /home/ssd0/zc/palo/doris/core/be/src/service/doris_main.cpp:159
+ #3 0x7f573b5eebd4 in __libc_start_main (/opt/compiler/gcc-4.8.2/lib64/libc.so.6+0x21bd4)
+
+SUMMARY: LeakSanitizer: 1024 byte(s) leaked in 1 allocation(s).
+```
+
+从上述的输出中,我们能看到有1024个字节被泄露了,并且打印出来了内存申请时的堆栈信息。
+
+**注意:开启这个选项是要影响程序的执行性能的,请慎重对线上的实例开启**
+
+**注意:如果开启了LSAN开关的话,tcmalloc就会被自动关闭**
+
+### ASAN
+
+除了内存使用不合理、泄露以外。有的时候也会发生内存访问非法地址等错误。这个时候我们可以借助[ASAN](https://github.com/google/sanitizers/wiki/AddressSanitizer)来辅助我们找到问题的原因。与LSAN一样,ASAN也集成在了GCC中。Doris通过如下的方式进行编译就能够开启这个功能
+
+```
+BUILD_TYPE=ASAN ./build.sh
+```
+
+执行编译生成的二进制文件,当检测工具发现有异常访问时,就会立即退出,并将非法访问的堆栈输出在be.out中。对于ASAN的输出与LSAN是一样的分析方法。这里我们也主动注入一个地址访问错误,来展示下具体的内容输出。我们仍然在`StorageEngine`的`open`函数中注入一段非法内存访问,具体的错误代码如下
+
+```
+ char* invalid_buf = new char[1024];
+ for (int i = 0; i < 1025; ++i) {
+ invalid_buf[i] = i;
+ }
+ LOG(INFO) << invalid_buf;
+```
+
+然后我们就会在be.out中获得如下的输出
+
+```
+=================================================================
+==23284==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61900008bf80 at pc 0x00000129f56a bp 0x7fff546eed90 sp 0x7fff546eed88
+WRITE of size 1 at 0x61900008bf80 thread T0
+ #0 0x129f569 in doris::StorageEngine::open(doris::EngineOptions const&, doris::StorageEngine**) /home/ssd0/zc/palo/doris/core/be/src/olap/storage_engine.cpp:106
+ #1 0xe2c1e3 in main /home/ssd0/zc/palo/doris/core/be/src/service/doris_main.cpp:159
+ #2 0x7fa5580fbbd4 in __libc_start_main (/opt/compiler/gcc-4.8.2/lib64/libc.so.6+0x21bd4)
+ #3 0xd30794 (/home/ssd0/zc/palo/doris/core/output3/be/lib/palo_be+0xd30794)
+
+0x61900008bf80 is located 0 bytes to the right of 1024-byte region [0x61900008bb80,0x61900008bf80)
+allocated by thread T0 here:
+ #0 0xdeb040 in operator new[](unsigned long) ../../../../gcc-7.3.0/libsanitizer/asan/asan_new_delete.cc:82
+ #1 0x129f50d in doris::StorageEngine::open(doris::EngineOptions const&, doris::StorageEngine**) /home/ssd0/zc/palo/doris/core/be/src/olap/storage_engine.cpp:104
+ #2 0xe2c1e3 in main /home/ssd0/zc/palo/doris/core/be/src/service/doris_main.cpp:159
+ #3 0x7fa5580fbbd4 in __libc_start_main (/opt/compiler/gcc-4.8.2/lib64/libc.so.6+0x21bd4)
+
+SUMMARY: AddressSanitizer: heap-buffer-overflow /home/ssd0/zc/palo/doris/core/be/src/olap/storage_engine.cpp:106 in doris::StorageEngine::open(doris::EngineOptions const&, doris::StorageEngine**)
+```
+
+从这段信息中该可以看到在`0x61900008bf80`这个地址我们尝试去写一个字节,但是这个地址是非法的。我们也可以看到 `[0x61900008bb80,0x61900008bf80)`这个地址的申请堆栈。
+
+**注意:开启这个选项是要影响程序的执行性能的,请慎重对线上的实例开启**
+
+**注意:如果开启了ASAN开关的话,tcmalloc就会被自动关闭**
+
+另外,如果be.out中输出了堆栈信息,但是并没有函数符号,那么这个时候需要我们手动的处理下才能获得可读的堆栈信息。具体的处理方法需要借助一个脚本来解析ASAN的输出。这个时候我们需要使用[asan_symbolize](https://llvm.org/svn/llvm-project/compiler-rt/trunk/lib/asan/scripts/asan_symbolize.py)来帮忙解析下。具体的使用方式如下:
+
+```
+cat be.out | python asan_symbolize.py | c++filt
+```
+
+通过上述的命令,我们就能够获得可读的堆栈信息了。
+
+## CPU
+
+当系统的CPU Idle很低的时候,说明系统的CPU已经成为了主要瓶颈,这个时候就需要分析一下当前的CPU使用情况。对于Doris的BE可以有如下两种方式来分析Doris的CPU瓶颈。
+
+### pprof
+
+由于Doris内部已经集成了并兼容了GPerf的REST接口,那么用户可以通过`pprof`工具来分析远程的Doris BE。具体的使用方式如下:
+
+```
+pprof --svg --seconds=60 http://be_host:be_webport/pprof/profile > be.svg
+```
+
+这样就能够生成一张BE执行的CPU消耗图。
+
+
+
+### perf + flamegragh
+
+这个是相当通用的一种CPU分析方式,相比于`pprof`,这中方式必须要求能够登陆到分析对象的物理机上。但是相比于pprof只能定时采点,perf是能够通过不同的事件来完成堆栈信息采集的。具体的的使用方式如下:
+
+```
+perf record -g -p be_pid -- sleep 60
+```
+
+这条命令会统计60秒钟BE的CPU运行情况,并且生成perf.data。对于perf.data的分析,可以通过perf的命令来进行分析
+
+```
+perf report
+```
+
+分析得到如下的图片
+
+
+
+来对生成的内容进行分析。当然也可以使用flamegragh完成可视化展示。
+
+```
+perf script | ./FlameGraph/stackcollapse-perf.pl | ./FlameGraph/flamegraph.pl > be.svg
+```
+
+这样也会生成一张当时运行的CPU消耗图。
+
+
diff --git a/docs/documentation/en/developer-guide/debug-tool.md b/docs/documentation/en/developer-guide/debug-tool.md
new file mode 100644
index 0000000000..530506a043
--- /dev/null
+++ b/docs/documentation/en/developer-guide/debug-tool.md
@@ -0,0 +1,247 @@
+# Debug Tool
+
+In the process of using and developing Doris, we often encounter scenarios that need to debug Doris. Here are some common debugging tools.
+
+## Preparing
+
+[pprof] (https://github.com/google/pprof): from gperftools, it is used to transform the content generated by gperftools into a format that is easy for people to read, such as PDF, SVG, text, etc.
+
+[graphviz] (http://www.graphviz.org/): in the absence of this library, pprof can only be converted to text format, but this way is not easy to view. After the library is installed, pprof can be converted to SVG, PDF and other formats, and the call relationship is clearer.
+
+[perf] (https://perf.wiki.kernel.org/index.php/main_page): Linux kernel comes with performance analysis tool. [here] (http://www.brendangregg.com/perf.html) there are some examples of perf usage.
+
+[flamegraph] (https://github.com/brendangregg/flamegraph): a visualization tool used to show the output of perf in the form of flame graph.
+
+## Memory
+
+Debugging memory is generally divided into two aspects. One is whether the total amount of memory use is reasonable. On the one hand, the excessive amount of memory use may be due to memory leak in the system, on the other hand, it may be due to improper use of program memory. The second is whether there is a problem of memory overrun and illegal access, such as program access to memory with an illegal address, use of uninitialized memory, etc. For the debugging of memory, we usually use the following ways to track the problems.
+
+### Log
+
+When we find that the memory usage is too large, we can first check the be.out log to see if there is a large memory application. Because of the TCMalloc currently used by Doris to manage memory, when a large memory application is encountered, the stack of the application will be printed to the be.out file. The general form is as follows:
+
+```
+tcmalloc: large alloc 1396277248 bytes == 0x3f3488000 @ 0x2af6f63 0x2c4095b 0x134d278 0x134bdcb 0x133d105 0x133d1d0 0x19930ed
+```
+
+This indicates that Doris be is trying to apply memory of '1396277248 bytes' on this stack. We can use the 'addr2line' command to restore the stack to a letter that we can understand. The specific example is shown below.
+
+```
+$ addr2line -e lib/palo_be 0x2af6f63 0x2c4095b 0x134d278 0x134bdcb 0x133d105 0x133d1d0 0x19930ed
+
+/home/ssd0/zc/palo/doris/core/thirdparty/src/gperftools-gperftools-2.7/src/tcmalloc.cc:1335
+/home/ssd0/zc/palo/doris/core/thirdparty/src/gperftools-gperftools-2.7/src/tcmalloc.cc:1357
+/home/disk0/baidu-doris/baidu/bdg/doris-baidu/core/be/src/exec/hash_table.cpp:267
+/home/disk0/baidu-doris/baidu/bdg/doris-baidu/core/be/src/exec/hash_table.hpp:86
+/home/disk0/baidu-doris/baidu/bdg/doris-baidu/core/be/src/exec/hash_join_node.cpp:239
+/home/disk0/baidu-doris/baidu/bdg/doris-baidu/core/be/src/exec/hash_join_node.cpp:213
+thread.cpp:?
+```
+
+### HEAP PROFILE
+
+Sometimes the application of memory is not caused by the application of large memory, but by the continuous accumulation of small memory. Then there is no way to locate the specific application information by viewing the log, so you need to get the information through other ways.
+
+At this time, we can take advantage of TCMalloc's [heapprofile](https://gperftools.github.io/gperftools/heapprofile.html). If the heapprofile function is set, we can get the overall memory application usage of the process. The usage is to set the 'heapprofile' environment variable before starting Doris be. For example:
+
+```
+export HEAPPROFILE=/tmp/doris_be.hprof
+./bin/start_be.sh --daemon
+```
+
+In this way, when the dump condition of the heapprofile is met, the overall memory usage will be written to the file in the specified path. Later, we can use the 'pprof' tool to analyze the output content.
+
+```
+$ pprof --text lib/palo_be /tmp/doris_be.hprof.0012.heap | head -30
+
+Using local file lib/palo_be.
+Using local file /tmp/doris_be.hprof.0012.heap.
+Total: 668.6 MB
+ 610.6 91.3% 91.3% 610.6 91.3% doris::SystemAllocator::allocate_via_malloc (inline)
+ 18.1 2.7% 94.0% 18.1 2.7% _objalloc_alloc
+ 5.6 0.8% 94.9% 63.4 9.5% doris::RowBatch::RowBatch
+ 5.1 0.8% 95.6% 7.1 1.1% butil::ResourcePool::add_block (inline)
+ 3.7 0.5% 96.2% 3.7 0.5% butil::iobuf::create_block (inline)
+ 3.4 0.5% 96.7% 3.4 0.5% butil::FlatMap::init
+ 3.2 0.5% 97.2% 5.2 0.8% butil::ObjectPool::add_block (inline)
+ 2.6 0.4% 97.6% 2.6 0.4% __gnu_cxx::new_allocator::allocate (inline)
+ 2.0 0.3% 97.9% 2.0 0.3% butil::ObjectPool::add_block_group (inline)
+ 2.0 0.3% 98.2% 2.0 0.3% butil::ResourcePool::add_block_group (inline)
+ 1.7 0.3% 98.4% 1.7 0.3% doris::SegmentReader::_load_index
+```
+
+Contents of each column of the above documents:
+
+* Column 1: the memory size directly applied by the function, in MB
+* Column 4: the total memory size of the function and all the functions it calls.
+* The second column and the fifth column are the proportion values of the first column and the fourth column respectively.
+* The third column is the cumulative value of the second column.
+
+Of course, it can also generate call relation pictures, which is more convenient for analysis. For example, the following command can generate a call graph in SVG format.
+
+```
+pprof --svg lib/palo_be /tmp/doris_be.hprof.0012.heap > heap.svg
+```
+
+**NOTE: turning on this option will affect the execution performance of the program. Please be careful to turn on the online instance.**
+
+### pprof remote server
+
+Although heapprofile can get all the memory usage information, it has some limitations. 1. Restart be. 2. You need to enable this command all the time, which will affect the performance of the whole process.
+
+For Doris be, you can also use the way of opening and closing the heap profile dynamically to analyze the memory application of the process. Doris supports the [remote server debugging of gperftools](https://gperftools.github.io/gperftools/pprof_remote_servers.html). Then you can use 'pprof' to directly perform dynamic head profile on the remote running Doris be. For example, we can check the memory usage increment of Doris through the following command
+
+```
+$ pprof --text --seconds=60 http://be_host:be_webport/pprof/heap
+
+Total: 1296.4 MB
+ 484.9 37.4% 37.4% 484.9 37.4% doris::StorageByteBuffer::create
+ 272.2 21.0% 58.4% 273.3 21.1% doris::RowBlock::init
+ 157.5 12.1% 70.5% 157.5 12.1% doris::RowBatch::RowBatch
+ 90.7 7.0% 77.5% 90.7 7.0% doris::SystemAllocator::allocate_via_malloc
+ 66.6 5.1% 82.7% 66.6 5.1% doris::IntegerColumnReader::init
+ 47.9 3.7% 86.4% 47.9 3.7% __gnu_cxx::new_allocator::allocate
+ 20.8 1.6% 88.0% 35.4 2.7% doris::SegmentReader::_load_index
+ 12.7 1.0% 89.0% 12.7 1.0% doris::DecimalColumnReader::init
+ 12.7 1.0% 89.9% 12.7 1.0% doris::LargeIntColumnReader::init
+ 12.7 1.0% 90.9% 12.7 1.0% doris::StringColumnDirectReader::init
+ 12.3 0.9% 91.9% 12.3 0.9% std::__cxx11::basic_string::_M_mutate
+ 10.4 0.8% 92.7% 10.4 0.8% doris::VectorizedRowBatch::VectorizedRowBatch
+ 10.0 0.8% 93.4% 10.0 0.8% doris::PlainTextLineReader::PlainTextLineReader
+```
+
+The output of this command is the same as the output and view mode of heap profile, which will not be described in detail here. Statistics will be enabled only during execution of this command, which has a limited impact on process performance compared with heap profile.
+
+### LSAN
+
+[LSAN](https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer) is an address checking tool, GCC has been integrated. When we compile the code, we can enable this function by turning on the corresponding compilation options. When the program has a determinable memory leak, it prints the leak stack. Doris be has integrated this tool, only need to compile with the following command to generate be binary with memory leak detection version.
+
+```
+BUILD_TYPE=LSAN ./build.sh
+```
+
+When the system detects a memory leak, it will output the corresponding information in be. Out. For the following demonstration, we intentionally insert a memory leak code into the code. We insert the following code into the `open` function of `StorageEngine`.
+
+```
+ char* leak_buf = new char[1024];
+ strcpy(leak_buf, "hello world");
+ LOG(INFO) << leak_buf;
+```
+
+We get the following output in be.out
+
+```
+=================================================================
+==24732==ERROR: LeakSanitizer: detected memory leaks
+
+Direct leak of 1024 byte(s) in 1 object(s) allocated from:
+ #0 0xd10586 in operator new[](unsigned long) ../../../../gcc-7.3.0/libsanitizer/lsan/lsan_interceptors.cc:164
+ #1 0xe333a2 in doris::StorageEngine::open(doris::EngineOptions const&, doris::StorageEngine**) /home/ssd0/zc/palo/doris/core/be/src/olap/storage_engine.cpp:104
+ #2 0xd3cc96 in main /home/ssd0/zc/palo/doris/core/be/src/service/doris_main.cpp:159
+ #3 0x7f573b5eebd4 in __libc_start_main (/opt/compiler/gcc-4.8.2/lib64/libc.so.6+0x21bd4)
+
+SUMMARY: LeakSanitizer: 1024 byte(s) leaked in 1 allocation(s).
+```
+
+From the above output, we can see that 1024 bytes have been leaked, and the stack information of memory application has been printed out.
+
+**NOTE: turning on this option will affect the execution performance of the program. Please be careful to turn on the online instance.**
+
+**NOTE: if the LSAN switch is turned on, the TCMalloc will be automatically turned off**
+
+### ASAN
+
+Except for the unreasonable use and leakage of memory. Sometimes there will be memory access illegal address and other errors. At this time, we can use [ASAN](https://github.com/google/sanitizers/wiki/addresssanitizer) to help us find the cause of the problem. Like LSAN, ASAN is integrated into GCC. Doris can open this function by compiling as follows
+
+```
+BUILD_TYPE=ASAN ./build.sh
+```
+
+Execute the binary generated by compilation. When the detection tool finds any abnormal access, it will immediately exit and output the stack illegally accessed in be.out. The output of ASAN is the same as that of LSAN. Here we also actively inject an address access error to show the specific content output. We still inject an illegal memory access into the 'open' function of 'storageengine'. The specific error code is as follows
+
+```
+ char* invalid_buf = new char[1024];
+ for (int i = 0; i < 1025; ++i) {
+ invalid_buf[i] = i;
+ }
+ LOG(INFO) << invalid_buf;
+```
+
+We get the following output in be.out
+
+```
+=================================================================
+==23284==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x61900008bf80 at pc 0x00000129f56a bp 0x7fff546eed90 sp 0x7fff546eed88
+WRITE of size 1 at 0x61900008bf80 thread T0
+ #0 0x129f569 in doris::StorageEngine::open(doris::EngineOptions const&, doris::StorageEngine**) /home/ssd0/zc/palo/doris/core/be/src/olap/storage_engine.cpp:106
+ #1 0xe2c1e3 in main /home/ssd0/zc/palo/doris/core/be/src/service/doris_main.cpp:159
+ #2 0x7fa5580fbbd4 in __libc_start_main (/opt/compiler/gcc-4.8.2/lib64/libc.so.6+0x21bd4)
+ #3 0xd30794 (/home/ssd0/zc/palo/doris/core/output3/be/lib/palo_be+0xd30794)
+
+0x61900008bf80 is located 0 bytes to the right of 1024-byte region [0x61900008bb80,0x61900008bf80)
+allocated by thread T0 here:
+ #0 0xdeb040 in operator new[](unsigned long) ../../../../gcc-7.3.0/libsanitizer/asan/asan_new_delete.cc:82
+ #1 0x129f50d in doris::StorageEngine::open(doris::EngineOptions const&, doris::StorageEngine**) /home/ssd0/zc/palo/doris/core/be/src/olap/storage_engine.cpp:104
+ #2 0xe2c1e3 in main /home/ssd0/zc/palo/doris/core/be/src/service/doris_main.cpp:159
+ #3 0x7fa5580fbbd4 in __libc_start_main (/opt/compiler/gcc-4.8.2/lib64/libc.so.6+0x21bd4)
+
+SUMMARY: AddressSanitizer: heap-buffer-overflow /home/ssd0/zc/palo/doris/core/be/src/olap/storage_engine.cpp:106 in doris::StorageEngine::open(doris::EngineOptions const&, doris::StorageEngine**)
+```
+
+From this message, we can see that at the address of `0x61900008bf80`, we tried to write a byte, but this address is illegal. We can also see the application stack of the address `[0x61900008bb80, 0x61900008bf80]`.
+
+**NOTE: turning on this option will affect the execution performance of the program. Please be careful to turn on the online instance.**
+
+**NOTE: if the ASAN switch is turned on, the TCMalloc will be automatically turned off**
+
+In addition, if stack information is output in be.out, but there is no function symbol, then we need to handle it manually to get readable stack information. The specific processing method needs a script to parse the output of ASAN. At this time, we need to use [asan_symbolize](https://llvm.org/svn/llvm-project/compiler-rt/trunk/lib/asan/scripts/asan_symbolize.py) to help with parsing. The specific usage is as follows:
+
+```
+cat be.out | python asan_symbolize.py | c++filt
+```
+
+With the above command, we can get readable stack information.
+
+## CPU
+
+When the CPU idle of the system is very low, it means that the CPU of the system has become the main bottleneck. At this time, it is necessary to analyze the current CPU usage. For the be of Doris, there are two ways to analyze the CPU bottleneck of Doris.
+
+### pprof
+
+Because Doris has integrated and compatible with GPERF rest interface, users can analyze remote Doris be through the 'pprof' tool. The specific usage is as follows:
+
+```
+pprof --svg --seconds=60 http://be_host:be_webport/pprof/profile > be.svg
+```
+
+In this way, a CPU consumption graph of be execution can be generated.
+
+
+
+### perf + flamegragh
+
+This is a quite common CPU analysis method. Compared with `pprof`, this method must be able to log in to the physical machine of the analysis object. However, compared with pprof, which can only collect points on time, perf can collect stack information through different events. The specific usage is as follows:
+
+```
+perf record -g -p be_pid -- sleep 60
+```
+
+This command counts the CPU operation of be for 60 seconds and generates perf.data. For the analysis of perf.data, the command of perf can be used for analysis.
+
+```
+perf report
+```
+
+The analysis results in the following pictures
+
+
+
+To analyze the generated content. Of course, you can also use flash graph to complete the visual display.
+
+```
+perf script | ./FlameGraph/stackcollapse-perf.pl | ./FlameGraph/flamegraph.pl > be.svg
+```
+
+This will also generate a graph of CPU consumption at that time.
+
+
diff --git a/docs/resources/images/cpu-flame-demo.svg b/docs/resources/images/cpu-flame-demo.svg
new file mode 100644
index 0000000000..f08a8a7605
--- /dev/null
+++ b/docs/resources/images/cpu-flame-demo.svg
@@ -0,0 +1,3587 @@
+
+
+
diff --git a/docs/resources/images/cpu-pprof-demo.png b/docs/resources/images/cpu-pprof-demo.png
new file mode 100644
index 0000000000..2eb659b1d0
Binary files /dev/null and b/docs/resources/images/cpu-pprof-demo.png differ
diff --git a/docs/resources/images/cpu-pprof-demo.svg b/docs/resources/images/cpu-pprof-demo.svg
new file mode 100644
index 0000000000..8f00bbb81c
--- /dev/null
+++ b/docs/resources/images/cpu-pprof-demo.svg
@@ -0,0 +1,1879 @@
+
+
+
+
+
diff --git a/docs/resources/images/perf-report-demo.png b/docs/resources/images/perf-report-demo.png
new file mode 100644
index 0000000000..e702f08c7d
Binary files /dev/null and b/docs/resources/images/perf-report-demo.png differ