1
votes

GC setting is:

Min, max, total JVM size (-Xms -Xmx)

JVM_SIZE="-Xms24g -Xmx24g"

New Generation Sizes (-Xmn)

JVM_SIZE_NEW="-Xmn2g"

Type of Garbage Collector to use

JVM_GC_TYPE="-XX:+UseConcMarkSweepGC -XX:+UseParNewGC"

Tuning options for the above garbage collector

JVM_GC_OPTS="-XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=75 -XX:SurvivorRatio=8 -XX:+CMSParallelRemarkEnabled -XX:+CMSScavengeBeforeRemark -XX:+UseCMSCompactAtFullCollection -XX:+CMSClassUnloadingEnabled"

Maybe 24g is too bigger for CMS?

2014-03-03T19:34:10.687+0800: 74.121: [GC [1 CMS-initial-mark: 1431731K(23068672K)] 3170863K(24956160K), 0.8289630 secs] [Times: user=0.83 sys=0.00, real=0.83 secs] Total time for which application threads were stopped: 0.8294730 seconds

1
For heaps that large you should also seriously consider G1.Marko Topolnik

1 Answers

0
votes

Maybe 24g is too bigger for CMS?

It depends on you business, is it need that much or it could work with less that 24g.

However, the memory separated by 2 maim spaces, young and old. this two spaces are collected separately, so to enable CMS you need to use ‑XX:+UseConcMarkSweepGC

CMS will collect the young if its got filled or for a period of time. and there is some recommendations to set the young space as the following:

-XX:MaxNewSize=  -> this need to be 40% from your Xmx value
-XX:NewSize= -> this need to be 40% from your Xmx value

This will speed up GC and make it more accurate. which means that the old will not fill that fast (avoiding the Premature Promotion objects).

also for controlling GC delay you could use:

–XX:CMSWaitDuration= -delay in ms-