well, you didnt mentioned all arguments you set, but
you could try to set
-XX:+ScavengeBeforeFullGC
and you should also think about your Object
s lifecycle. how long do your applications Object
s live and what size are the Object
s.
think about it and take a look at the following arguments
-XX:NewRatio=n old/new ration (default 2)
-XX:SurvivorRatio=n eden/survivor ratio (default 8)
-XX:MaxTenuringThreshold=n number of times, objects are moved from survivor one to survivor two and vice versa before objects are moved to old-gen (default 15)
with default values
Xms and Xmx are set to 32gb -> old gen = 16gb and new gen 16gb -> eden 14gb -> survivors 2gb (there are two, each of it at the size of 1gb)
eden contains all Object
s that are instantiated by new Object
.
one survivor (to-survivor) is always empty. the other ones (from-survivor) contains Object
s that survived a minor gc
surviving Object
s from eden and from from-survivor go into to-survivor at minor gc
if the standard-size of 1gb of this ‘default-configuration’ exceeds, Object
s go into old-gen
if it does not exceed, after 15 minor gc’s (-XX:MaxTenuringThreshold
s default value), Object
s go into old-gen
by tweaking those values, always keep in mind, old-gen has to be as large as or larger than new-gen, cause a gc can cause the whole new-gen to go into old-gen
Edit
a timeline of your first “old gen: used” picture would be helpful
keep in mind that there is no need to do a full gc until old gen doesn’t exceed – a full gc causes the whole “world” to stop for a certain period of time
in this particular case, i would say you could
- reduce
-Xms
and-Xmx
to 8gb - set/decrease
-XX:SurvivorRatio
s value to 2 - set/increase
-XX:MaxTenuringThreshold
to 50
and you will get an old and new gen, each sized 4gb,
eden at size of 2gb,
two survivors, each sized 1gb,
and aproximately 50 minor gc’s, before Object
s go into old gen