Understanding High Object Copy Times
nezihyigitbasi at gmail.com
Fri Apr 28 00:20:44 UTC 2017
Thanks for the suggestions. We use the default pause time. And here is our
entire set of JVM args:
I have some followup questions:
- In some case the object copy took 39406.8 ms, even if the remembered set
is ~30GB isn't this too slow (that's <1GB/s of data)?
- Is there any way to reduce the rset overhead?
- My initial thought when I saw the high object copy times was there may be
some sort of contention to have such a low throughput during the copy.
Although it may not be the case here, I just wonder whether there is a way
to see the amount of contention from the gc logs?
2017-04-27 16:58 GMT-07:00 Jenny Zhang <yu.zhang at oracle.com>:
> Hi, Hezih,
> It seems this workload is very heavy on Remember Set. It has about 31G
> native memory for RSet (old gen) and still with coarsening.
> What is you pause time goal? The default (200ms) might be too small for
> you. Can you increase that so G1 can increase the young gen size? Since
> there is not much promotion, I guess most of the object copy time is
> dealing with the Remember Set.
> There are other things you can try, like increase the G1RSetReginEntries,
> but the memory footprint will be bigger.
> So if you can, I suggest increase the pause time goal first.
> On 4/27/2017 9:22 AM, nezih yigitbasi wrote:
>> We see huge object copy times (and relatively high termination times)
>> during young GCs in our production system running on Java 1.8.0_112-b15.
>> You can find the GC logs here: https://gist.github.com/nezihy
>> The young GC times start going high after the timestamp
>> I will appreciate if you can give some details about:
>> - what goes into the "Object Copy" phase during young GCs and how we can
>> reduce it.
>> - why we see high Termination times and what we can do about it
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-gc-dev