1) From these params young gc size is very low.  Set the -Xmn with a higher 
memory let's say 1g. if your data is short lived than long-lived then you can 
try it making 2g or less.
2) Since -XX:SurvivorRatio is 8 here so both   Survivors getting 1/8 of young 
gc (i.e allocated to -Xmn). Have them something like -XX:SurvivorRatio=3.
3) Can have -XX:TargetSurvivorRatio=90
4) Why u don't try ParallelOldGC since your heap size 4g is not very high, this 
algo should able to keep it up. It by default enables AdaptiveSizePolicy to 
automatically adjust the survivors spaces, in that case you don't need  
-XX:SurvivorRatio option.

Regards,
Rahul

-----Original Message-----
From: Azuryy Yu [mailto:[email protected]]
Sent: 09 December 2012 15:25
To: [email protected]
Subject: Please review my GC options, and give me some advice.

hi,
I found sometimes yong gc is very slow, it paused more than 14 seconds.
GC log:
1383.531: [GC 1383.531: [ParNew: 235968K->26176K(235968K), 14.1752210 secs]
1518208K->1356662K(4168128K), 14.6084490 secs] [Times: user=9.77
1518208K->sys=0.14,
real=14.61 secs]
Total time for which application threads were stopped: 14.6241190 seconds

jstat : (jstat -gc -h 10 20010 1000)

          S0C    S1C    S0U    S1U      EC       EU        OC
OU       PC     PU    YGC     YGCT    FGC    FGCT     GCT
          26176.0 26176.0 26176.0 26176.0 209792.0 209792.0 3932160.0
1315008.8  163840.0 22007.9    434  330.795  14      3.943  334.738
         26176.0 26176.0 26176.0 26176.0 209792.0 209792.0 3932160.0
1315008.8  163840.0 22007.9    434  330.795  14      3.943  334.738
         26176.0 26176.0 26176.0  0.0   209792.0   0.0    3932160.0
1330486.2  163840.0 22007.9    434  344.970  14      3.943  348.913

Eden, S0, S1 are all full, then yong gc paused more than 14 seconds. please 
give me some advice, appreciate much!

1) I used:
java version "1.7.0_09"
Java(TM) SE Runtime Environment (build 1.7.0_09-b05) Java HotSpot(TM) 64-Bit 
Server VM (build 23.5-b02, mixed mode)

2) My JVM options as follow(yong objects have a short life generally, so
-Xmn256m):
-Xmx4g -Xms4g -Xmn256m  -server -verbose:gc -XX:+PrintGCTimeStamps 
-XX:+PrintGCDetails -XX:+PrintGCApplicationStoppedTime
-XX:-HeapDumpOnOutOfMemoryError -XX:+UseGCLogFileRotation
-XX:NumberOfGCLogFiles=9 -XX:GCLogFileSize=20m -XX:+DisableExplicitGC 
-XX:+UseCompressedOops -XX:PermSize=160m -XX:MaxPermSize=160m
-XX:GCTimeRatio=19 -XX:SoftRefLRUPolicyMSPerMB=0 -XX:SurvivorRatio=8
-XX:MaxTenuringThreshold=6 -XX:+UseParNewGC -XX:+UseConcMarkSweepGC 
-XX:+CMSParallelRemarkEnabled -XX:CMSInitiatingOccupancyFraction=70
-XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 
-XX:+CMSClassUnloadingEnabled -XX:CMSMaxAbortablePrecleanTime=300
-XX:+CMSScavengeBeforeRemark
-XX:ErrorFile=/usr/local/hase/logs/rs_error_gc.log
-Xloggc:/usr/local/hbase/logs/rs_gc.log
-XX:HeapDumpPath=/usr/local/hbase/logs/rs_error.hprof
This email and any attachments are confidential, and may be legally privileged 
and protected by copyright. If you are not the intended recipient dissemination 
or copying of this email is prohibited. If you have received this in error, 
please notify the sender by replying by email and then delete the email 
completely from your system. Any views or opinions are solely those of the 
sender. This communication is not intended to form a binding contract unless 
expressly indicated to the contrary and properly authorised. Any actions taken 
on the basis of this email are at the recipient's own risk.

Reply via email to