Hi, On Sat, 2016-10-08 at 14:30 -0400, Vitaly Davidovich wrote: > > > On Friday, October 7, 2016, Gopal, Prasanna CWK <prasanna.gopal@black > rock.com> wrote: > > Hi All > > > > > > Thanks for all your reply. These discussions certainly help to get > > good insight J. > > > > So just to summarize > > > > 1) G1ReservePercent will not affect Humongus allocation , so > > the full GC we are encountering is due to fragmentation > > > It may or may not - let's see what a G1 dev says (as Jenny > mentioned). Either way, you don't have enough contiguous regions to > satisfy the allocation, so it's fragmentation one way or the other. > > You should drop G1ReservePercent for now unless you have good reason > for setting it to 40 (that's a large value, btw).
See the other email in this thread. > > 2) I will try chaging G1MixedGCLiveThresholdPercent to 85 to > > see the mixed GC’s can be increased. > > > Yes, that's a good idea. Do you see any mixed GCs at all now? If so, > how long are the concurrent marking phases taking (look for > concurrent-mark-end in the gc log). Agree. Making G1 more aggressive with reclaiming old gen regions may help. With 8u40+, some simple, quite effective heuristics were added that in many cases decrease fragmentation a lot. With 7, you can only either give G1 more memory, try to make it more aggressively reclaim regions, or minimize old gen allocations that cause fragmentation. > > 3) Due to some other dependencies , we were unable to move to > > latest Jdk’s ( Jdk 8). Our application is currently running with > > CMS and we are seeing long GC pause , that why we wanted to explore > > G1.As we can’t move Jdk 8 soon , Is it good idea to migrate to G1 > > with Jdk 7 Please at least move to latest 7u (I remember you mentioning 7u40). There were a few very useful patches for G1 in 7u60 iirc. > Have you tried just setting Xmx and a reasonable pause time goal? > As a rule of thumb, setting Xmx to 3x your live set works > well(the more headroom you give to G1, the better). Giving it > a reasonable pause time goal allows it to adjust young gen > dynamically and possibly raising it high enough such that there's > either no promotion or very little - young gen collection efficiency > is a function of how many survivors you have when the collection > kicks in, so the fewer survivors the better (that applies > to all generational copying collectors, not just G1 of course). Thanks, Thomas _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
