http://dmouse.iteye.com/blog/1264118
jvm内存设置及总结
博客分类： java相关
Application情况：
大量使用了内存缓存，应用负载量较大，900w/d-1000w/d，对响应速度要求较高，因此gc造成的应用中断现象需要尽量控制在最小范围内。
系统情况：
2个8核的cpu，共2*8=16的处理器（processor），总大小为16G的内存。
调优方式：
1、-Xms -Xmx
设置初始堆最大和最小内存；经过测试，目前tomcat容器可以设置的最大内存为3G
-Xms3072M -Xmx3072M，避免gc后jvm重新分配内存，影响性能
2、-Xmn
设置年轻带Young Gen的内存大小，sun官方推荐Young Gen为整个堆内存的3/8，设置过小的Young Gen，会导致minor collection过于频繁，虽然提高了系统吞吐，确也提高了应用中断次数和时间，对于需要快速响应的服务而言不太适合，因此提高Young Gen是提升性能很关键的一步。
-Xmn1024M
3、设置collector
collector为垃圾收集器，目前主要有三种，serial collector(串行收集器)、parallel collector(并行收集器)、concurrent collector(并发收集器)
JDK5.0以前都是使用串行收集器，如果想使用其他收集器需要在启动时加入相应参数。JDK5.0以后，JVM会根据当前系统配置进行判断。
parallel collector(并行收集器)：以thoughout吞吐量为目标
concurrent collector(并发收集器)：以响应时间为目标，尽量减小gc造成的应用中断，以牺牲CPU为代价，提高了CPU的使用率
-Xms3g -Xmx3g -Xmn1g -XX:PermSize=128M -XX:+PrintGCDetails -XX:+UseParNewGC -XX:ParallelGCThreads=16 -XX:+UseConcMarkSweepGC
4、failed
promotion failed
参考http://blogs.oracle.com/jonthecollector/entry/when_the_sum_of_the
concurrent mode failure
参考 http://blogs.oracle.com/jonthecollector/entry/what_the_heck_s_a
jvm调整成如上参数后，似乎gc的时间短了，中断的次数和时间也大大提升，但是意外的发现了几次如下的错误
Java代码 收藏代码
[GC [ParNew (promotion failed): 839835K->840090K(943744K), 0.2078800 secs][CMS[Unloading class sun.reflect.GeneratedMethodAccessor661]
[GC [ParNew (promotion failed): 843545K->843165K(943744K), 0.4597140 secs][CMS[Unloading class sun.reflect.GeneratedMethodAccessor1018]
[GC [ParNew (promotion failed): 841739K->840457K(943744K), 0.2063630 secs][CMS[CMS-concurrent-sweep: 3.139/3.521 secs] [Times: user=10.76 sys=0.57, real=3.52 secs]
(concurrent mode failure)[Unloading class sun.reflect.GeneratedSerializationConstructorAccessor1790]
promotion failed和concurrent mode failure都会造成应用程序的中断，即所谓的stop-the-world。
a)产生上述问题的原因，原文是这样描述的（if theconcurrent collector is unable to finish reclaiming the unreachable objectsbefore the tenured generation fills up, or if an allocation cannot be satisfiedwith the available free space blocks in the tenured generation, then theapplication is paused and the collection is completed with all the applicationthreads stopped），简单解释就是old gen剩余的内存不足以满足来自于young gen的垃圾回收，导致jvm通过卸载已经生成的反射类来释放足够的内存。这种现象会造成应用较长时间的中断，从而影响性能。所以理论上应该保证eden + from survivor < old gen区剩余内存。
解决方法可以参考如下：通过设置-XX:CMSInitiatingOccupancyFraction=50（此值的初始值为10，即预留10%的空间给minor collection），当old gen已经收集了50%的内存后，就开始进行major collection，从而保证old gen 始终预留50%的可用内存。
这种设置虽然会提高major collection的频率，但是根据目前major collection的频率来看（大概几个小时一次）足以承受。
b)promotion failed，也会因为old gen 的碎片太多为进行过内存重组和压缩，无法提供一块较大的、连续的内存空间。解决方法可以通过设置参数-XX:+UseCMSCompactAtFullCollection（打开对年老代的压缩）-XX:CMSFullGCsBeforeCompaction（设置运行多少次FULL GC以后对内存空间进行压缩、整理）