大数据组件GC问题
GC，指Garbage Collection 是JAVA中的垃圾收集器。
相关组件的常见GC问题
1、Namenode的堆内存配置过小导致频繁产生full GC导致namenode宕机，在hadoop中，数据的写入&读取经由namenode，所以namenode的jvm内存需要足够多，尤其是在出现大量数据流动的场景中。建议nameNodejava -Xmx的值为4G 左右并随着文件数增加做相应调整
此外Hadoop集群中的文件数越多，Namenode的内存压力越大，可以通过archive归档命令定期合并一些目录以减少namenode的压力。hadoop不适于存储海量小文件的原因也在于此。
2、DataNode根据客户端或者是namenode的调度存储和检索数据，并且定期向namenode发送他们所存储的块(block)的列表。所以相应占用内存较小所以的内存可以相应调小。
3、NodeManager充当shuffle任务的server端，内存应该调大，否则会出现任务连接错误，日志Too Many fetch failures.Failing the attempt。或者NodeManager异常宕掉 日志为java.lang.OutOfMemoryError: GC overheadlimit exceeded 建议java堆内存调整到2G或以上
4、ResourceManager垃圾回收时间过长导致oom问题宕机或与zk的连接超时，出现active RM的频繁切换，此过程中会导致一些MR任务失败。或在系统运行高峰期，YARN的RM无法登录或登录界面现实特别慢。应用执行也特别慢。可以通过增加jvm 相应的堆大小或优化Gc参数避免Full GC 时间过长问题。
5、HRegionServer的堆内存配置过少，HBase的读写直接与RegionServer交换，Regionserver中预留了数据读写的缓存，入Memstore&blockCache等等，因此留给RegionServer的堆内存应足够其缓存数据库中的数据。
综上以上问题原因为GC 回收时间太长或堆内存不够形成的
yarn 上Gc 一般可分为三种
普通GC，CMS GC，FULL GC
Minor GC：
2017-02-16T09:53:26.409+0800: 135825.482: [GC (Allocation Failure) 2017-02-16T09:53:26.409+0800: 135825.482: [ParNew: 114914K->9992K(118016K), 0.0119158 secs] 1843767K->1739516K(2084096K), 0.0122177 secs] [Times: user=0.12 sys=0.00, real=0.01 secs] 16T09:53:26.409+0800:
解释
017-02-16T09:53:26.409+0800：： GC发生的时间；
135825.482：：GC开始，相对JVM启动的相对时间，单位是秒；
GC：：区别Minor GC、CMS GC、Full GC的标识，这次代表的是Minor GC；
Allocation Failure：： MinorGC的原因，在这个case里边，由于年轻代不满足申请的空间，因此触发了MinorGC;
ParNew ：：收集器的名称，它预示了年轻代使用一个并行的 mark-copy stop-the-world 垃圾收集器；
114914K->9992K：：收集前后年轻代的使用情况；
(118016K)：：整个年轻代的容量；
0.0119158 secs：：回收操作所用时间；
1843767K->1739516K：：收集前后整个堆的使用情况；
(2084096K)：：整个堆的容量；
0.0122177 secs：：ParNew收集器标记和复制年轻代活着的对象所花费的时间（包括和老年代通信的开销、对象晋升到老年代时间、垃圾收集周期结束一些最后的清理对象等的花销）；
CMS GC：（当系统繁忙时，会出现CMS GC，此时说明系统已经非常繁忙了，内存不足了。CMS的目标是尽量减少应用的暂停时间，减少full gc发生的几率。）
2017-02-16T09:53:26.934+0800: 135826.007: [CMS-concurrent-mark: 0.481/0.505 secs] [Times: user=4.27 sys=0.44, real=0.50 secs]
2017-02-16T
注
CMS GC 主要适合场景是对响应时间的重要性需求 大于对吞吐量的要求，能够承受垃圾回收线程和应用线程共享处理器资源，并且应用中存在比较多的长生命周期的对象的应用。CMS是用于对tenured generation的回收，也就是年老代的回收，目标是尽量减少应用的暂停时间，减少full gc发生的几率，利用和应用程序线程并发的垃圾回收线程来标记清除年老代。在我们的应用中，因为有缓存的存在，并且对于响应时间也有比较高的要求，因此希 望能尝试使用CMS来替代默认的server型JVM使用的并行收集器，以便获得更短的垃圾回收的暂停时间，提高程序的响应性。
FULL GC：
2017-02-15T10:37:23.957+0800: 53139.489: [Full GC (Allocation Failure) 2017-02-15T10:37:23.957+0800: 53139.490: [CMS: 1966079K->1966079K(1966080K), 4.4891712 secs] 2084073K->1970966K(2084096K), [Metaspace: 67007K->67007K(1110016K)], 4.4894022 secs] [Times: user=4.49 sys=0.00, real=4.49 secs]
如果出现FULL GC，那么说明系统已经出现问题，4.4891712 secs表示整个JVM都停顿了4.48秒。服务由于full gc 暂停卡顿引起的tcp连接
注；出现Gc 情况
1 、调用System.gc
2.老年代空间不足
3、永生区空间不足
4、CMS GC时出现promotion failed和concurrent mode failure
5、统计得到的Minor GC晋升到旧生代的平均大小大于老年代的剩余空间
6、堆中分配很大的对象
Full GB 导致问题
Full GC本身是好的，可以清除老年代的垃圾，但是如果Full GC发生的频率高了，就会影响性能，同时意味着系统内存分配机制出现问题。
因为Full GC本身执行时间较长（甚至超过1秒），而且除非采用G1 GC，否则其它的GC方式都会或多或少挂起所有线程执行（Stop-the-world），如果Full GC频繁发生，系统被挂起的次数就会增加，响应时间就会变慢甚至进程出现问题。
同时，Full GC频繁发生，意味着你的内存分配机制存在问题，也许是内存泄露，有大量内存垃圾不断在老年代产生；也许是你的大对象（缓存）过多；也有可能是你的参数设置不好，minor GC清理不掉内存，导致每次minor GC都会触发Full GC；还有可能是你的老年代大小参数设置错误，老年代过小等等原因
监控GC 问题
实时监控
java 内置命令 通过 jps 查看组件进程id 即pid
jstat -gcutil <时间间隔（ms）> 例如：jstat -gcutil 157333 3000
[root@ZW0805-hadoop-87 ~]# jstat -gcutil 122189 100
S0 S1 E O M CCS YGC YGCT FGC FGCT GCT
0.00 17.62 46.31 99.51 97.91 95.30 638 4.155 38855 858.796 862.951
0.00 17.62 46.32 99.51 97.91 95.30 638 4.155 38855 858.796 862.951
0.00 17.62 46.48 99.51 97.91 95.30 638 4.155 38855 858.796 862.951
0.00 17.62 46.65 99.51 97.91 95.30 638 4.155 38855 858.796 862.951
0.00 17.62 46.65 99.51 97.91 95.30 638 4.155 38855 858.796 862.951
0.00 17.62 46.90 99.51 97.91 95.30 638 4.155 38855 858.796 862.951
0.00 17.62 46.91 99.51 97.91 95.30 638 4.155 38855 858.796 862.951
0.00 17.62 46.91 99.51 97.91 95.30 638 4.155 38855 858.796 862.951
0.00 17.62 46.92 99.51 97.91 95.30 638 4.155 38855 858.796 862.951
0.00 17.62 46.96 99.51 97.91 95.30 638 4.155 38855 858.796 862.951
0.00 17.62 46.97 99.51 97.91 95.30 638 4.155 38855 858.796 862.951
S0 ：： Heap上的 Survivor space 0 区已使用空间的百分比（年轻代中第一个survivor（幸存区）已使用的占当前容量百分比）
S1 ：： Heap上的 Survivor space 1 区已使用空间的百分比 （年轻代中第二个survivor（幸存区）已使用的占当前容量百分比）
E ：： Heap上的 Eden space 区已使用空间的百分比 （年轻代中Eden（伊甸园）已使用的占当前容量百分比）
O ：： Heap上的 Old space 区已使用空间的百分比 （old代已使用的占当前容量百分比）
P ：： Perm space 区已使用空间的百分比（perm代已使用的占当前容量百分比）
YGC ：： 从应用程序启动到采样时发生 Young GC 的次数
YGCT：：从应用程序启动到采样时 Young GC 所用的时间(单位秒)
FGC ：： 从应用程序启动到采样时发生 Full GC 的次数 （从应用程序启动到采样时old代(全gc)gc次数）
FGCT：：从应用程序启动到采样时 Full GC 所用的时间(单位秒) （从应用程序启动到采样时old代(全gc)gc所用时间(s)）
GCT ：： 从应用程序启动到采样时用于垃圾回收的总时间(单位秒)
通过FGC我们可以发现系统是否发生FULL GC和FULL GC的频率
若要监控一段时间GC 状态 可以通过GC 大日志 最后解析日志
注参照参数打印日志
-XX:+PrintTenuringDisribution
-XX:+PrintGC
-XX:+PrintGCDetails
-XX:+PrintGCApplicationStoppedTime
-Xloggc:/clouderalogs/var/log/gclog
注意：java中垃圾回收整体过程为：
1.新生区垃圾回收
类诞生、成长、消亡的区域，一个类在这里产生，应用，最后被垃圾回收器收集，结束生命。
新生区分为两部分： 伊甸区（Eden space）和幸存者区（Survivor pace） ，所有的类都是在伊甸区被new出来的。幸存区有两个： 0区（Survivor 0 space）和1区（Survivor 1 space）。当伊甸园的空间用完时，程序又需要创建对象，JVM的垃圾回收器将对伊甸园区进行垃圾回收(Minor GC)，将伊甸园区中的不再被其他对象所引用的对象进行销毁。然后将伊甸园中的剩余对象移动到幸存 0区。若幸存 0区也满了，再对该区进行垃圾回收，然后移动到1区。如果1区的满了之后进入老年区。
2.老年区
新生区经过多次GC仍然存活的对象移动到老年区。若老年区也满了，那么这个时候将产生MajorGC（FullGC），进行老年区的内存清理。若老年区执行了Full GC之后发现依然无法进行对象的保存，就会产生OOM异常“OutOfMemoryError”
3.元数据区：元数据区取代了永久代(jdk1.8以前)，本质和永久代类似，都是对JVM规范中方法区的实现，区别在于元数据区并不在虚拟机中，而是使用本地物理内存，永久代在虚拟机中，永久代逻辑结构上属于堆，但是物理上不属于堆，堆大小=新生代+老年代。元数据区也有可能发生OutOfMemory异常。
-
Full GC == Major GC指的是对老年代/永久代的stop the world的GC
-
Full GC的次数 = 老年代GC时 stop the world的次数
-
Full GC的时间 = 老年代GC时 stop the world的总时间
#第四第五条需深入学习研究（带验证）
4. CMS 不等于Full GC，我们可以看到CMS分为多个阶段，只有stop the world的阶段被计算到了Full GC的次数和时间，而和业务线程并发的GC的次数和时间则不被认为是Full GC
- Full GC本身不会先进行Minor GC，我们可以配置，让Full GC之前先进行一次Minor GC，因为老年代很多对象都会引用到新生代的对象，先进行一次Minor GC可以提高老年代GC的速度。比如老年代使用CMS时，设置CMSScavengeBeforeRemark优化，让CMS remark之前先进行一次Minor GC。
参考GC方式异同
https://blog.csdn.net/hellozhxy/article/details/80649342