再议jvm调优技巧
?完全信息:
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差不多,可以接受)?
?
