ResourceManager GC


ResourceManager GC


GC,指Garbage Collection 是JAVA中的垃圾收集器。

現象

在系統運行高峯期,YARN的RM無法登錄或登錄界面現實特別慢。應用執行也特別慢。

分析與解決方案

根據經驗,系統RM無法登錄,那麼有可能是RM進程有問題,所以查看RM進行日誌。

查看RM的GC日誌resourcemanager-omm-20170214200940-pid13297-gc.log.8,發現大量的FULL GC。

2017-02-16T09:53:27.389+0800: 135826.463: [GC (Allocation Failure) 2017-02-16T09:53:27.389+0800: 135826.463: [ParNew: 114712K->10438K(118016K), 0.0059636 secs] 1844453K->1740908K(2084096K), 0.0062153 secs] [Times: user=0.09 sys=0.01, real=0.00 secs]

 出現FULL GC說明RM內存已用光,無可分配資源,故無法RM出現hang住狀態。

解決方案:

  • 調整RM的最大可用內存限制
  • 重啓YARN

詳解知識點

在YARN的GC日誌中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:

2017-02-16T09:53:26.425+0800: 135825.498: [GC (CMS Initial Mark) [1 CMS-initial-mark: 1729524K(1966080K)] 1739924K(2084096K), 0.0034278 secs] [Times: user=0.02 sys=0.00, real=0.00 secs] 

 在GC日誌中此正常情況下會進出現此日誌。其中1844453K->1740908K(2084096K) 內存總:2084096K 已用內存從1844453K釋放到1740908K

2017-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收集器標記和複製年輕代活着的對象所花費的時間(包括和老年代通信的開銷、對象晉升到老年代時間、垃圾收集週期結束一些最後的清理對象等的花銷);

[Times: user=0.12 sys=0.00, real=0.01 secs]::GC事件在不同維度的耗時,具體的用英文解釋起來更加合理:

  • user : Total CPU time that was consumed by Garbage Collector threads during this collection
  • sys : Time spent in OS calls or waiting for system event
  • real : Clock time for which your application was stopped. With Parallel GC this number should be close to (user time + system time) divided by the number of threads used by the Garbage Collector. In this particular case 8 threads were used. Note that due to some activities not being parallelizable, it always exceeds the ratio by a certain amount.


CMS GC:

2017-02-16T09:53:25.805+0800: 135824.878: [CMS-concurrent-sweep-start]

2017-02-16T09:53:26.161+0800: 135825.234: [CMS-concurrent-sweep: 0.356/0.356 secs] [Times: user=0.46 sys=0.01, real=0.36 secs] 

2017-02-16T09:53:26.161+0800: 135825.234: [CMS-concurrent-reset-start]

2017-02-16T09:53:26.169+0800: 135825.243: [CMS-concurrent-reset: 0.009/0.009 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]

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-16T09:53:26.934+0800: 135826.008: [CMS-concurrent-preclean-start]

2017-02-16T09:53:26.964+0800: 135826.038: [CMS-concurrent-preclean: 0.028/0.030 secs] [Times: user=0.04 sys=0.00, real=0.03 secs] 

2017-02-16T09:53:26.964+0800: 135826.038: [CMS-concurrent-abortable-preclean-start]

當系統繁忙時,會出現CMS GC,此時說明系統已經非常繁忙了,內存不足了。CMS的目標是儘量減少應用的暫停時間,減少full gc發生的機率。


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秒。


jstat查看GC

jstat -gcutil <pid> <時間間隔(ms)>
例如:jstat -gcutil 15743 3000

運行結果如下:

[omm@HDM03 rm]$ jstat -gcutil 15743 3000

       S0     S1         E     O      M     CCS    YGC     YGCT    FGC    FGCT     GCT   

100.00   0.00  66.79  63.13  98.55  96.57  27560  330.003   78       2.388  332.391

 73.12   0.00  15.32  63.35  98.55  96.57  27562  330.028    78       2.388  332.416

  0.00  54.64  29.29  63.35  98.55  96.57  27563  330.036    78       2.388  332.424

 55.43   0.00  57.75  63.35  98.55  96.57  27564  330.044    78       2.388  332.432

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的頻率 


Icon

關於GC的詳細介紹請參考《深入理解 Java 垃圾回收機制》

 



發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章