再议jvm调优技巧

 

一.调优原则

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差不多,可以接受)