garbage collection - Java GC - Understanding TargetSurivorRatio -

having gc problem can't seem fix , hoping can provide insight. real fix add additional jvm's accommodate load, that's out of power time being.

my question if explain nuances of -xx:targetsurvivorratio

from description:

if application being fine-tuned has relatively consistent object allocation rate, acceptable raise target survivor occupancy high -xx:targetsurvivorratio=80 or -xx:targetsurvivorratio=90. advantage of being able helps reduce amount of survivor space needed age objects. challenge setting -xx:targetsurvivorratio= higher hotspot vm not being able better adapt object aging in presence of spikes in object allocation rates, can lead tenuring objects sooner like

spikes in object allocation rates i'm suffering from, shown below: 2015-07-07t15:24:56.592-0500: 2760.113: [gc 2760.113: [parnew desired survivor size 483183816 bytes, new threshold 5 (max 5) - age 1: 105182048 bytes, 105182048 total - age 2: 220512 bytes, 105402560 total - age 3: 292176 bytes, 105694736 total - age 4: 303792 bytes, 105998528 total - age 5: 494584 bytes, 106493112 total : 3155059k->104104k(3670016k), 0.1605850 secs] 10036522k->6986163k(15204352k), 0.1611320 secs] [times: user=0.29 sys=0.00, real=0.16 secs] 2015-07-07t15:25:06.838-0500: 2770.359: [gc 2770.359: [parnew desired survivor size 483183816 bytes, new threshold 5 (max 5) - age 1: 405021040 bytes, 405021040 total - age 2: 114464 bytes, 405135504 total - age 3: 175872 bytes, 405311376 total - age 4: 292176 bytes, 405603552 total - age 5: 302512 bytes, 405906064 total : 3249821k->398565k(3670016k), 0.1744060 secs] 10131880k->7281107k(15204352k), 0.1747200 secs] [times: user=0.34 sys=0.00, real=0.18 secs] 2015-07-07t15:25:14.251-0500: 2777.772: [gc 2777.772: [parnew desired survivor size 483183816 bytes, new threshold 1 (max 5) - age 1: 536174616 bytes, 536174616 total - age 2: 202152 bytes, 536376768 total - age 3: 66784 bytes, 536443552 total - age 4: 175440 bytes, 536618992 total - age 5: 292176 bytes, 536911168 total : 3544293k->524288k(3670016k), 1.3915370 secs] 10426835k->8124824k(15204352k), 1.3919310 secs] [times: user=2.70 sys=0.00, real=1.40 secs] 2015-07-07t15:25:24.958-0500: 2788.479: [gc 2788.479: [parnew desired survivor size 483183816 bytes, new threshold 5 (max 5) - age 1: 9526032 bytes, 9526032 total : 3670016k->155222k(3670016k), 0.3542590 secs] 11270552k->7846132k(15204352k), 0.3546270 secs] [times: user=0.67 sys=0.01, real=0.36 secs]

my java_opts follows:

-xms15360m -xmx15360m -xx:maxpermsize=512m -xx:+cmsclassunloadingenabled -xx:+useconcmarksweepgc -verbose:gc -xx:+printgcdetails -xx:+printgcdatestamps -xloggc:logs/gc.log -xx:+usecmsinitiatingoccupancyonly -xx:cmsinitiatingoccupancyfraction=65 -xx:newsize=4096m -xx:maxnewsize=4096m -xx:survivorratio=6 -xx:+printtenuringdistribution -xx:permsize=512m -xx:-useadaptivesizepolicy -xx:+disableexplicitgc -xx:+scavengebeforefullgc -xx:maxtenuringthreshold=5 -xx:targetsurvivorratio=90

i've been decreasing survivorratio (increasing available survivor space), , increasing newsize proportionally, seems no matter do, spikes 20-80 mb greater survivor space , continue promote garbage.

back question @ hand.. decreasing targetsurvivorratio spikes? , if how? wouldn't setting 50% decrease available survivor space drastically, causing me prematurely promote more often? , other input have how can survive first highly-allocated collection appreciated. thank you

update

after hours of reading it, days spent researching prior posting, think landed on conclusion question. targetsurvivorratio=90 setting use-case. in order set memory usage of survivor space close targetratio, jvm dynamically choose tenuring threshold (limited maxtenuring, of course) in order meet desired goal.

in case, objects more or less tenured after age 4, , small. accommodating age: 1 top priority -- extremely large number of surviving objects don't live see age: 2. need survivor space available possible, since have over-sized jvm, limited space in old gen, , no ability assign additional heap. use-case not "spike in object allocation rates", thought option referring to... it's 1 massive spike.

where lower target ratio beneficial scenarios maxtenuringthreshold set high number, , carries steady amount of tenured objects way through. if increased number of newly tenured objects survive, , targetratio set high, jvm unable adjust tenuring threshold prevent premature promotion.

as overall fix problem.. increasing survivor size lowering ratio and/or increasing young gen size