Y Srinivas Ramakrishna
Y.S.Ramakrishna at Sun.COM
Tue Oct 28 18:03:34 UTC 2008
Hi Sujit --
> We have a distributed trading application. I have a processor set of
> 16 CPU bound to process A and 8 CPU to process B. Please consider
> following scenarios:
> Scenario1: ParallelGCThreads set to 16 for both Process A and B.
16 for Process B is definitely the wrong setting. You should use
8 or less for Process B, since it has only an 8 processor pset to run on.
> Scenario2: ParallelGCThreads set to 8 for both Process A and B.
> Now for scenario2, I see that threadstop time has increased (got
> worse) for process A and reduced (improved) for process B. Is this an
> expected behaviour? Also will this (# of ParallelGCThreads vs # of
> CPUs) impact rate of minor collections?
Yes, exactly as expected. In Scenario 2, you have more than 8 cpu's
available for GC of A, so using more than 8 GC threads is paying off.
If you exceed the # cpu's available, however, gc times will increase.
That's what you saw in the case of B going from Scenario 2 to Scenario 1.
#parallel gc threads does not affect the time between parallel collections,
but only the duration of the collections. The time between gcs is affected
(mainly) by the size of Eden and speed of the mutators.
> Thanks and Regards,
> This e-mail and any files transmitted with it are for the sole use of
> the intended recipient(s) and may contain confidential and privileged
> If you are not the intended recipient, please contact the sender by
> reply e-mail and destroy all copies of the original message.
> Any unauthorized review, use, disclosure, dissemination, forwarding,
> printing or copying of this email or any action taken in reliance on
> this e-mail is strictly prohibited and may be unlawful.
> hotspot-gc-use mailing list
> hotspot-gc-use at openjdk.java.net
hotspot-gc-use mailing list
hotspot-gc-use at openjdk.java.net
More information about the hotspot-gc-dev