We are using the throughput collector too, but I did not look at the ergonomics (i.e. specifying criteria).
I'll give it a shot and see how it performs. In your application, how did you find it performed? What size of eden did it settle on?
Robert
| peter royal <[EMAIL PROTECTED]>
02/05/2006 17:39
|
To: [email protected] cc: Subject: Re: Performance - some interesting results |
On May 2, 2006, at 4:01 AM, [EMAIL PROTECTED] wrote:
Another thing that would be useful would be to run with verbosegc output so we can understand what impact the garbage collector is having.
I found that increasing the eden size was very beneficial - since we want to minimise the number of full GCs. I found for my tests that a heap of 1GB with an eden size of 300MB worked well, e.g. -Xms1024m -Xmx1024m -XX:NewSize=300m. On jrockit the default eden size is better (for me) since it increases in line with the number of CPUs but to set it manually specify -Xns (n for nursery).
You've found that explicit sizing helps? I've been using the Throughput collector, which in Java5, will self-tune the generations. I've been specifying 'MaxGCPauseMillis' .. (This is based off of reading http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html#0.0.0.0.Adjusting%20Generation%20Sizes%7Coutline )
-pete
--
[EMAIL PROTECTED] - http://fotap.org/~osi
This communication is for informational purposes only. It is not intended
as an offer or solicitation for the purchase or sale of any financial
instrument or as an official confirmation of any transaction. All market prices,
data and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of JPMorgan Chase & Co., its subsidiaries
and affiliates.
