一.调优原则
1.heap size尽量不太大,合适就好.否则回收(mark)时间会偏长;new gen同理
e.g.
2013-10-13T23:01:02.707+0800: 104720.333: [GC [1 CMS-initial-mark: 3826274K(6291456K)] 4924537K(8126464K), 0.6017570 secs] [Times: user=0.63 sys=0.00, real=0.60 secs]
有60ms的花费时间
1.2 选择合理的collect type
1.3 尽量避免promotion 或concurrent failed.产生这个基本上是设计不合理的表现,这将产生过多时间在full gc
2.尽量少在app中存储size大的objects.以免减少collections
3.响应时间优先还是throughtput取决于你的需求 cms有很好的响应时间,曲线比较平滑,但回收频繁;其它collector由不频繁但偶尔回收时间过长. 即使同样是cms也是如此,就看具体设置 4.如果确实是大并发请求,建议使用balance 5.gc优化没有最好,只有更好.达到目标就好,不要过多时间花费在这,花点时间在代码或架构上 ------对于以上情况,我想到比较好的办法是,先用直接设置Xmx,Xms Xloggs三项,让jvm自行选择. 跑一天后再观察实现情况,看看gc number和old ratio.得到初步数据后再进行逐步调优.完全信息:
2013-10-13T23:01:02.707+0800: 104720.333: [GC [1 CMS-initial-mark: 3826274K(6291456K)] 4924537K(8126464K), 0.6017570 secs] [Times: user=0.63 sys=0.00, real=0.60 secs]
2013-10-13T23:01:03.309+0800: 104720.935: [CMS-concurrent-mark-start]
2013-10-13T23:01:03.482+0800: 104721.109: [CMS-concurrent-mark: 0.172/0.173 secs] [Times: user=0.38 sys=0.00, real=0.17 secs]
2013-10-13T23:01:03.482+0800: 104721.109: [CMS-concurrent-preclean-start]
2013-10-13T23:01:03.897+0800: 104721.523: [CMS-concurrent-preclean: 0.327/0.414 secs] [Times: user=0.44 sys=0.00, real=0.41 secs]
2013-10-13T23:01:03.897+0800: 104721.523: [CMS-concurrent-abortable-preclean-start]
CMS: abort preclean due to time 2013-10-13T23:01:09.098+0800: 104726.725: [CMS-concurrent-abortable-preclean: 4.801/5.202 secs] [Times: user=4.99 sys=0.00, real=5.20 secs]
2013-10-13T23:01:09.099+0800: 104726.725: [GC[YG occupancy: 1108749 K (1835008 K)]2013-10-13T23:01:09.099+0800: 104726.725: [GC 104726.725: [ParNew: 1108749K->174622K(1835008K), 0.2987860 secs] 4935023K->4000896K(8126464K), 0.2988370 secs] [Times: user=1.54 sys=0.00, real=0.30 secs] 104727.024: [Rescan (parallel) , 0.0834900 secs]104727.108: [weak refs processing, 0.0000070 secs]104727.108: [class unloading, 0.0023390 secs]104727.110: [scrub symbol & string tables, 0.0019500 secs] [1 CMS-remark: 3826274K(6291456K)] 4000896K(8126464K), 0.3872130 secs] [Times: user=1.96 sys=0.00, real=0.39 secs]
2013-10-13T23:01:09.486+0800: 104727.113: [CMS-concurrent-sweep-start]
2013-10-13T23:01:09.660+0800: 104727.286: [CMS-concurrent-sweep: 0.172/0.174 secs] [Times: user=0.18 sys=0.00, real=0.17 secs]
2013-10-13T23:01:09.660+0800: 104727.286: [CMS-concurrent-reset-start]
2013-10-13T23:01:09.712+0800: 104727.339: [CMS-concurrent-reset: 0.052/0.052 secs] [Times: user=0.01 sys=0.00, real=0.06 secs]
由于我们使用了-XX:+CMSScavengeBeforeRemark,所以在remark前有一个"GC 104726.725: [ParNew",但由于这是parallel,所以最终的花费时间并不是由它产生,而是由remark本身时间引起的.
补充:parallel是app本身多线程执行;concurrent是除此这外,它与其它apps也是并行的.
二.评估原则 evaluation principle /EP
可能不同的需求有不的标准,但通常对于web门户来说按重要性可以归纳为几点:
１.total gc time
主要是major gc time.不能单纯看gc number,这个可以看出某个jvm settings的总体情况
２.cost time / gc
通常应用希望可以得到比较平滑的响应时间,不是高低不稳
３.full gc number and time
出现full gc通常时间比较长,当然不可能避免它,但始终越少越好了
4.current old gen ratio
如果当前占比大,这也意味着接近full gc 可能性大了.当然如果已经跑了很久,那么也未尝不可
1 day gc example:
case S0 S1 E O P YGC YGCT FGC FGCT GCT avg cost time /gc
1 9.18 0.00 77.80 39.21 37.71 1406 53.707 0 0.000 53.707 40
２ 0.00 13.95 67.79 59.19 37.71 1527 46.035 0 0.000 46.035 30
３ 0.00 100.00 63.19 30.57 37.53 777 47.609 2 0.269 47.878 60
４ 0.00 32.25 66.60 40.12 37.71 1049 51.251 0 0.000 51.251 50
５ 0.00 29.12 4.33 35.88 37.36 1973 59.679 0 0.000 59.679 30
对于五种不同的jvm setttings,我比较倾向于２,下面对着EP逐项分析
１.total gc time
2,3,4是较好的,blocking
２.cost time / gc
2,4是比较好的,blocking
３.full gc number and time 二个都没有4.current old gen ratio 由于跑了一天时间,接近60%上限,可以接受full gc即将出现(况且后来真的出现了,而且时间也就60ms左右,跟其它minor gc差不多,可以接受)