Hi Gopal, On Wed, 2017-02-08 at 16:28 +0000, Gopal, Prasanna CWK wrote: > Hi Thomas > > Thanks for your reply. We have following G1 configuration at the > moment > > [...] > Apart from these parameters, can we try another parameter to make the > evacuation more aggressive? >
It premature to try to make the collection more aggressive if e.g. there is not anything worth to reclaim anyway. > > -XX:G1MixedGCLiveThresholdPercent=85 You could increase that. Look at your "post-marking" output and see if there would be a significant additional amount of space to be reclaimed. Be aware that evacuating e.g. 90% full regions might be slow (and you will only ever get 10% back). Another option would be decreasing G1HeapWastePercent (not sure what the default is, but it is pretty low already iirc), which would more thoroughly clean out the collection set. Also being more aggressively evacuating may not help e.g. for problems with humongous objects/region fragmentation. If there is a lot of unusable memory at the end of humongous objects (check the "post-marking" output) actually decreasing region size might help. Eg. ### HUMS 0x000000079e000000- 0x00000007a0000000 33554432 33554432 33554432 501904008.8 ### HUMC 0x00000007a0000000- 0x00000007a2000000 2367536 2367536 2367536 2526909.9 indicates that that humongous object basically wastes 31M out of 64M, which is really bad if there are more of those hanging around. I do not see any good solution with g1 on 7u other than increasing the heap if that large a region size is necessary. If these humongous objects are short-lived (and do not have j.l.O. elements), then upgrading to 8u/9 may help (i.e. if eager reclaim can clean out large objects regularly and asap). Btw, the log also indicates 4121M out of 6144M of live data (around 3800M after hypothetically cleaning out all of old gen). This amount of live data may already beyond the comfort zone of most collectors. Only Jdk9 improves a bit in these situations, but not sure if the changes apply here. Not sure if decreasing heap region size will help a lot either as the heap is already relatively full. > -XX:InitiatingHeapOccupancyPercent=60 ==> we have experimented with > less values , it is just making the concurrent cycle without claiming > any significant. Actually even 60% seems to much. If your average live set size is at 61% already like in the log, G1 already runs marking all the time. > -XX:MaxGCPauseMillis=500 > > Our object allocation rate is very high, before increasing the memory > can we try any other parameter which can make the evacuation more > aggressive? Appreciate your help. Please do let me know, if you need > any more information. Thanks, Thomas _______________________________________________ hotspot-gc-use mailing list hotspot-gc-use@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/hotspot-gc-use
