4

My JAVA_OPTS is 

-server -Xms4g -Xmx4g -XX:MaxMetaspaceSize=384m -Xmn2g -Xloggc:/home/admin/logs/gc.log 
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+UseG1GC -XX:MaxGCPauseMillis=300

I'm satisfied with the frequency of Full GC,and the timespan between two GCs is 5 hours or longer. One of Full GCs' log is:

2016-11-29T03:59:18.009+0800: 385603.123: [Full GC (Allocation Failure)  4066M->1197M(4096M), 2.5124454 secs]
   [Eden: 0.0B(2048.0M)->0.0B(2048.0M) Survivors: 0.0B->0.0B Heap: 4066.4M(4096.0M)->1197.1M(4096.0M)], [Metaspace: 168228K->167780K(1206272K)]
[Times: user=3.24 sys=0.00, real=2.52 secs]

Is the Full GC of G1 Stop The World ? If so,the pause time is longer than 1 second,which is unacceptable.How to optimize ?

yichudu
  • 165
  • 2
  • 12
  • Try setting -XX:InitiatingHeapOccupancyPercent=70, it's default value is 45% of heap occupancy which maybe what is causing it to full GC too early. – fn. Nov 29 '16 at 10:11
  • @fn. PS:I'm satisfied with the frequency of Full GC,and the timespan between two GCs is 5 hours or longer. I concern the the length of pause time. – yichudu Nov 29 '16 at 11:11
  • 1
    Full GCs should not happen at all with G1, consider them a soft failure mode. Concurrent cycles / mixed collections should do the job all the time. Upload a complete GC log somewhere or anlyze it yourself with [gcviewer](https://github.com/chewiebug/GCViewer) – the8472 Nov 29 '16 at 12:45
  • @yichudu I agree with the8472, try running a tool to give you some insight, like gceasy.io (web-based) – fn. Nov 29 '16 at 21:47
  • I got the reason.There is a timer task who loads much data,1.8G about,into memory for updating some collections.So a time-consuming GC is unavoidable,unless I adjust the heap to bigger. – yichudu Dec 02 '16 at 09:27

1 Answers1

2

-Xmn2g is conflict with -XX:MaxGCPauseMillis=300.

G1 will dynamically adjust new generation size.

You should just delete the -Xmn2g.

Marcs
  • 3,768
  • 5
  • 33
  • 42
ACRusher
  • 36
  • 2