RSet Tuning

[charlie hunt]

> On Jun 1, 2015, at 2:17 PM, Simone Bordet <simone.bordet at gmail.com> wrote:
> 
> Hi,
> 
> On Mon, Jun 1, 2015 at 8:20 PM, charlie hunt <charlie.hunt at oracle.com> wrote:
>> The observations you mention here are certainly of interest to the team working on G1. If you would like to start a new thread on the performance and tuning of RSets I’d be glad to offer my $0.02. :-)
>> 
> 
> I'm interested in hearing about RSet tuning.
> 
> While I don't have the vast experience of Kirk in number of G1 cases
> tuned, for those that I worked on G1 was only able to respect the
> target pause for about 50% of the pauses with a max of about 3x the
> target pause.
> 
> Our data shows that for the 50% that exceeded the target pause there
> is no clear cause: sometimes is RSet scanning, sometimes RSet
> updating, sometimes Object copying, etc.
> 
> In the context of RSet tuning, what advices do you have ?

Your options to tuning RSet updating, G1 sets a target time to do RSet updating as a percentage of MaxGCPauseMillis. IIRC, this defaults to 10%. In an attempt to try to lower RSet update times, you could decrease this percentage using G1RSetUpdatingPauseTimePercent. However, there are tradeoffs / consequences to decreasing this value. For instance, assuming the same amount of load, with the same amount of buffers to be updated in a given interval, some of the RSet updates that had been done during a GC pause will get pushed off onto the concurrent refinement threads. In doing so, there will be more concurrent work and sharing of system resources (CPU cycles and CPU cache for instance). In the worst case where the concurrent refinement threads can’t keep up with number buffers that require updating, the mutator threads will jump in and help with the processing. And, this will of course slow down the application.

A command line option that may help a lot with RSet tuning is G1SummarizeRSetStats and G1SummarizeRSetStatsPeriod=1. At each GC pause, this will tell you how much RSet work is being done by the concurrent refinement threads. The two main areas to watch for are whether any of buffers were processed by the mutator threads. Ideally you would like these to be handled by the concurrent refinement threads. The other thing to watch for is whether any RSet coarsening is happening. RSet coarsening will likely end up increasing your RSet Update times. So coarsening is something to try to avoid. AFAIK, there are not too many options for avoiding RSet coarsening. One might consider decreasing the region size. The smaller region size would mean (potentially) a smaller number of incoming references into a given region. But, reducing region size has consequences too such as the potential for frequent large object allocations. 

You may need to increase the concurrent refinement threads if you are both decreasing G1RSetUpdatingPauseTimePercent and seeing the mutator threads processing buffers. The number of concurrent refinement threads defaults to a value based of the setting for ParallelGCThreads. But, it can be overridden with G1ConcRefinementThreads. As always, find the justification for changing the default values rather than just shooting in the dark and adopting flags and their values.

hths,

charlie


> 
> Thanks !
> 
> -- 
> Simone Bordet
> http://bordet.blogspot.com
> ---
> Finally, no matter how good the architecture and design are,
> to deliver bug-free software with optimal performance and reliability,
> the implementation technique must be flawless.   Victoria Livschitz