Tuning advice

[Keith Holdaway]

See comments embedded below:

Keith R Holdaway
Java Development Technologies

SAS The Power to Know

Carpe Diem


-----Original Message-----
From: hotspot-gc-dev-bounces at openjdk.java.net [mailto:hotspot-gc-dev-bounces at openjdk.java.net] On Behalf Of Shaffer, Kurt
Sent: Wednesday, March 12, 2008 11:21 AM
To: hotspot-gc-use at openjdk.java.net
Subject: RE: Tuning advice

Gurus,

I really appreciate your advice, I've been asked a question that I can't
answer.  Even though no one has noticed a "problem area" from the data
I've sent we are looking at trying some of the suggestions you all sent.
The question is what order if any should they be attempted in?  We have
done two, setting the heap sizes larger and removed ParalletGCThreads so
it defaults to 4 rather than the setting it used to be of 20 (4 cpu
system).  One of our Windchill apps person is saying that we are using
RMI and there is not way of working around the fact it is forcing a full
GC every 60 seconds except to upgrade to java 1.6.0.


[Keith Holdaway] Ridiculous statement :)
USE: -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 which enforces Distributed GC to ONE hour.

 He also stated
that suggestion 1 will only add another GC routine on top of the default
full GC currently being done.  I've attached an updated output from
PrintGCStats at the bottom of the email.  Recap of suggestions:
[Keith Holdaway] Don't listen to this guy, he obviously has no clue about GC! CMS is an Old Gen GC algorithm that if precluded from completing its several phases of work, will be interrupted by a FUll GC that collects Young and Old generations. CMS is used in the OG to reduce pauses seen sometimes by the default mark/sweep/compact algorithm in the OG.

1) Set -XX:+UseConcMarkSweepGC  to turn on the 'low pause'
ConcurentMarkSweep Collector of the old area.

2) By default this will also turn on -XX:+UseParNewGC for the new area,
so you will see lots of smaller ParNew Collections happening. This is
OK, a desirable frequency is perhaps 2-3 secs. You should probably
specify NewSize, the default with a 1GB heap will be 16mb which is
normally too small. Say try 48mb, ie -XX:NewSize=48m.

3) I note you are using 1.4.2-13. I know there is a 'feature' in update
12 which causes CMS Collections to always be initiated when heap is half
full. It is fixed in update 15, but I'm not sure about 13. This may not
be a problem to you, except you are effectively just using approx half
of the heap space. There is a workaround, specify
  -XX:CMSInitiatingOccupancyFraction=nn
-XX:+UseCMSInitiatingOccupancyOnly=true.
The default fraction is 68 (it is actually a percent).

4)  Do you use RMI? By default, RMI calls Full GC every 60 seconds for
the
correct operation of its distributed GC algorithm. The default behavior
has been changed in 6.0 to be something less frequent (once an hour I
believe...).

5)  Note that in 1.4.2_13 only the minor (young generation) collections
are done on many processors; full collections are still serial
collections.  If your logs show those collections to be the problem,
you might want to try the mostly-concurrent collector
(-XX:+UseConcMarkSweepGC) instead, but that will require different
tunings.



PrintGCStats output (4 cpus / 3 JVMs / Windchill application):

what         count       total      mean      max   stddev
gen0(s)         22      39.217   1.78260    2.710   0.4661
gen0t(s)        22      39.224   1.78289    2.711   0.4661
gen1t(s)       776    1845.592   2.37834    7.894   1.5820
GC(s)          798    1884.816   2.36192    7.894   1.5649
alloc(MB)       22   10289.001  467.68186  482.000   3.1980
promo(MB)       22    1427.789  64.89950   88.547  16.4298

alloc/elapsed_time    =  10289.001 MB /  47197.783 s  =   0.218 MB/s
alloc/tot_cpu_time    =  10289.001 MB / 188791.132 s  =   0.054 MB/s
alloc/mut_cpu_time    =  10289.001 MB / 181251.870 s  =   0.057 MB/s
promo/elapsed_time    =   1427.789 MB /  47197.783 s  =   0.030 MB/s
promo/gc0_time        =   1427.789 MB /     39.224 s  =  36.401 MB/s
gc_seq_load           =   7539.262 s  / 188791.132 s  =   3.993%
gc_conc_load          =      0.000 s  / 188791.132 s  =   0.000%
gc_tot_load           =   7539.262 s  / 188791.132 s  =   3.993%

_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
_______________________________________________
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use