jvm 参数调优

 

首先，保留几张有用的收集算法图（JDK5.0中JVM堆模型、GC垃圾收集详细解析 .）

分代/堆模型

 

基本GC收集算法

复制

 

标记清除(mark-sweep)

 

标记整理(mark-sweep-compact)

 

GC收集器类型

古老的串行收集器(Serial Collector)

 

吞吐量优先的并行收集器(Throughput Collector)

 

暂停时间优先的并发收集器(Concurrent Low Pause Collector-CMS

 (从上看出即便是cms,对应的年轻代还是serial串行的,即也会stop-the-word,see http://blog.csdn.net/pingnanlee/article/details/17559055;另外一点是这里标出的'并行年轻代回收'并不是进行cms前的步骤,这里只是给出模型而已.当然进行cms时也会出现年轻代回收,从以下可以看出):

2014-11-08T13:30:07.410+0800: 165047.736: [CMS-concurrent-mark-start]

2014-11-08T13:30:08.616+0800: 165048.943: [CMS-concurrent-mark: 1.207/1.207 secs] [Times: user=3.51 sys=0.09, real=1.21 secs] 

2014-11-08T13:30:08.617+0800: 165048.943: [CMS-concurrent-preclean-start]

2014-11-08T13:30:08.647+0800: 165048.974: [CMS-concurrent-preclean: 0.030/0.030 secs] [Times: user=0.03 sys=0.00, real=0.03 secs] 

2014-11-08T13:30:08.647+0800: 165048.974: [CMS-concurrent-abortable-preclean-start]

 CMS: abort preclean due to time 2014-11-08T13:30:14.114+0800: 165054.441: [CMS-concurrent-abortable-preclean: 5.466/5.467 secs] [Times: user=5.57 sys=0.10, real=5.47 secs] 

2014-11-08T13:30:14.115+0800: 165054.441: [GC[YG occupancy: 285633 K (2752512 K)]2014-11-08T13:30:14.115+0800: 165054.441: [GC 165054.441: [ParNew: 285633K->161210K(2752512K), 0.138

1660 secs] 7836081K->7719586K(15335424K), 0.1383540 secs] [Times: user=0.99 sys=0.34, real=0.14 secs] 

165054.580: [Rescan (parallel) , 0.0475440 secs]165054.628: [weak refs processing, 0.0042950 secs]165054.632: [class unloading, 0.0127620 secs]165054.645: [scrub symbol & string tab

 

les, 0.0055590 secs] [1 CMS-remark: 7558375K(12582912K)] 7719586K(15335424K), 0.2123320 secs] [Times: user=1.48 sys=0.34, real=0.21 secs] 

 

增量并发收集器(Incremental Concurrent-Mark-Sweep/i-CMS)

[1]（在单cpu情况下使用）

 

gc log format

其实不说我已经从调试上猜到了，不过还是有图直观（日志详解）

－－Young GC

 －－Full GC

 

 

由于现成资料已经很多了，下面主要针对一些关键问题依据自己的理解作答，如果有不妥欢迎指正。

 

0.优化原则是什么

首先在清楚，适用调优的条件是什么，何时适用？而且调优不是无极限，因为无非就是在minor gc与major gc之间取得一个平衡点，减少二者在一段时间内stop app time，而且不严重影响应用性能就足够。

这archive是说得有道理的。 When_to_Turn_On_Verbose_GC

 

1.JVM管理的内存有哪些

 

2.Young gen该多大

如果太小，对象存活期就很短，根本需要copy的对象就少了，但造成太频繁minor gc；否则对象基本在gc前就已经消亡，不需要或减少了gc，但这样造成每次收集时停留在遍历空间的成本时间较大。

这个参数需要根据具体应用权衡

 

3.何为minor gc & major gc

 

 

4.stop the word

 

 

5.收集器类型 VS 收集模型

 

 

6.收集分几代，触发时间

Gen	Usage	Trigger time
young
old
perm

 

 

 

 

 

 

 

 7.from survivor VS to

-任何时间只有一个survivor起作用，另外一个可以看作是‘备份’另一个；其实是当copy live objects to 'To'后，From 与‘To’的指针互相切换了。

-从地址空间和total size可以看出上述说法

 par new generation   total 18432K, used 13525K [0x00000000f4a00000, 0x00000000f5e00000, 0x00000000f5e00000)
  eden space 16384K,  82% used [0x00000000f4a00000, 0x00000000f57355b0, 0x00000000f5a00000)
  from space 2048K,   0% used [0x00000000f5a00000, 0x00000000f5a00000, 0x00000000f5c00000)
  to   space 2048K,   0% used [0x00000000f5c00000, 0x00000000f5c00000, 0x00000000f5e00000)

 

 8.若干实用参数

-XX:+PrintGCApplicationConcurrentTime:打印每次垃圾回收前，程序未中断的执行时间。可与上面混合使用
输出形式：Application time: 0.5291524 seconds

Instructs the VM to print out the amount of time the applications runs between collection pauses.
This flag is useful when tuning concurrent collectors.
-XX:+PrintGCApplicationStoppedTime：打印垃圾回收期间程序暂停的时间。可与上面混合使用
输出形式：Total time for which application threads were stopped: 0.0468229 seconds

Instructs the VM to print out the length of actual collection pauses.
This flag is useful when tuning concurrent collectors.

 

9. a cms example

//monopolize cpu,but cost little
2015-01-27T16:25:50.837+0800: 4076057.529: [GC [1 CMS-initial-mark: 10098755K(12582912K)] 10099524K(15335424K), 0.0007350 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 

//concurrent ,so time is long====
2015-01-27T16:25:50.838+0800: 4076057.530: [CMS-concurrent-mark-start]
2015-01-27T16:26:04.539+0800: 4076071.231: [CMS-concurrent-mark: 13.701/13.701 secs] [Times: user=39.19 sys=0.48, real=13.70 secs] 

2015-01-27T16:26:04.540+0800: 4076071.231: [CMS-concurrent-preclean-start]
2015-01-27T16:26:04.568+0800: 4076071.259: [CMS-concurrent-preclean: 0.028/0.028 secs] [Times: user=0.02 sys=0.00, real=0.03 secs] 
2015-01-27T16:26:04.568+0800: 4076071.259: [GC[YG occupancy: 768 K (2752512 K)]2015-01-27T16:26:04.568+0800: 4076071.260: [GC 4076071.260: [ParNew: 768K->0K(2752512K), 0.0162250 sec
s] 10099524K->10098755K(15335424K), 0.0163280 secs] [Times: user=0.16 sys=0.00, real=0.01 secs] 
4076071.276: [Rescan (parallel) , 0.0041890 secs]4076071.280: [weak refs processing, 0.0000070 secs]4076071.280: [class unloading, 0.0027570 secs]4076071.283: [scrub symbol & string
 tables, 0.0024770 secs] 
	//monopolize cpu,
	[1 CMS-remark: 10098755K(12582912K)] 10098755K(15335424K), 0.0270720 secs] 
[Times: user=0.21 sys=0.00, real=0.03 secs] 

//concurrent ,so time is long====
2015-01-27T16:26:04.595+0800: 4076071.287: [CMS-concurrent-sweep-start]
2015-01-27T16:26:09.607+0800: 4076076.298: [CMS-concurrent-sweep: 5.012/5.012 secs] [Times: user=5.16 sys=0.00, real=5.01 secs] 

2015-01-27T16:26:09.607+0800: 4076076.299: [CMS-concurrent-reset-start]
2015-01-27T16:26:09.635+0800: 4076076.326: [CMS-concurrent-reset: 0.027/0.027 secs] [Times: user=0.03 sys=0.00, real=0.03 secs] 

so exactly,this is cms is about(ms):19-(13+5)= 1000

 

 

 [1] jvm调优

认识 java JVM虚拟机选项 Xms Xmx PermSize MaxPermSize 区别 

JVM内存配置详解http://my.oschina.net/willSoft/blog/37615
Java 6 JVM参数选项大全http://kenwublog.com/docs/java6-jvm-options-chinese-edition.htm
http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html

http://hi.baidu.com/sdausea/item/f4671be89a7ec40d570f1d2d

http://niyunjiu.iteye.com/blog/337266

http://blog.csdn.net/kthq/article/details/8618052

http://hi.baidu.com/suofang/item/518ae93d487c3c80b711dbf5

http://blog.csdn.net/jiangguilong2000/article/details/8476361

oracle java G1 collector