概要描述
Inceptor Server 作为 TDH 中核心组件，负载一般都很高，经常会出现 GC 相关的问题，本案例提供一些 Inceptor Server 的 jmap 的分析思路以及注意事项，最后会列出来一些常见的 GC 相关的已知问题；
详细说明
本案例主要包含以下内容：
- 如何收集 jmap
- 通过 jmap 能分析出什么
- 如何分析 jmap
- Inceptor Server 常见的 GC 相关问题
如何收集 jmap
本案例旨在简单的分析一下 jmap histo 信息，所以只需要收集 jmap -histo:live 即可
# pid=jps |grep InceptorServer2 |awk {'print $1'}
# sudo -u hive jmap -histo:live $pid更详细的参考如下连接 ：JVM的内存分析命令解析
通过 jmap 能分析出什么
jmap Histogram 的主要作用是查看 instance 的数量和大小，一般用来查看应用程序创建的类实例的个数和实例占用大小，jdk 相关类可以忽略；
jmap Histogram 默认按照实例占用大小排序的，可以很容易看到占用内存最多的对象；
jmap Histogram 最后一行是统计信息，Total，可以看到 jvm 当前所有对象占用的大小；
如何分析 jmap
只关注我们能看懂的部分，数量（instance），大小（bytes），类对象（class name）；
因为不像c++的对象本身可以存放大量内存，java 的对象成员都是些引用，真正的内存都在堆上，看起来就是一堆原生的byte[], char[], int[]，所以我们看到 Histogram 图排在前面的往往是 char[]、byte[] ；因此如果我们只看对象本身，会发现内存都很小，此时我们需要关注实例对象的 instance 数量；
所以我们只需要关注数量异常多的，并且和服务（Inceptor）相关的 class；
举例说明一下
下图中 [C 占用比较多，但是并没办法看到具体内容，所以往下找和服务（Inceptor）相关的，有metastore.api和 metastore.api.Partition、hadoop.fs.FileSystem、hive.ql.parse；
可以向多级分区/小文件、复杂sql / sql并发方向考虑；
下图中，hadoop.fs.FileSystem 占用很大，说明应该是 hdfs 文件信息占用，具体的可以看到， java.net.URI 和 org.apache.hadoop.fs.Path 的数量基本相等，且达到 230W+ ，应该是 hdfs 文件路径信息，可以向小文件太多方向排查；
下图中，虽然排名靠前的两个是具体的 class ，如果看不懂，可以 Baidu 一下看看，然后我们在往下看，可以看到 io.transwarp.holodesk.storage.ds.column.block.filter.MinMaxBlockFilter 很多，这种情况应该是有频繁的 holodesk 写入操作，结合前面两个靠前的spark.Clean 相关class，可以向高并发的 holodesk 写入方向排查。
