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

[[email protected] ~]# 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

注
參考GC方式異同
https://blog.csdn.net/hellozhxy/article/details/80649342