Tomcat下高访问量WEB应用的JVM配置

61581229

　　JVM配置如下：
　　JAVA_OPTS="$JAVA_OPTS -server -Xmn1024M -Xms4096M -Xmx4096M  -Djava.net.preferIPv4Stack=true -Djava.awt.headless=true -Dorg.apache.catalina.connector.RECYCLE_FACADES=false -XX:PermSize=512M -XX:MaxPermSize=512M  -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0 -XX:+CMSClassUnloadingEnabled -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly  -XX:SurvivorRatio=65536 -XX:MaxTenuringThreshold=0 -XX:CMSInitiatingOccupancyFraction=81 -XX:SoftRefLRUPolicyMSPerMB=0 -Xloggc:gc.log -XX:+PrintGCDetails -Dcom.sun.management.jmxremote=true -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.port=29010 -Dcom.sun.management.jmxremote.ssl=false"
　　以上配置参数说明：
　　-XX:+UseCMSInitiatingOccupancyOnly 仅仅使用手动定义初始化定义开始CMS收集
-XX:+UseConcMarkSweepGC 使用CMS内存收集
-XX:+UseParNewGC 允许多线程收集新生代
-XX:+CMSParallelRemarkEnabled 降低标记停顿
-XX+UseCMSCompactAtFullCollection 在FULL GC的时候， 压缩内存， CMS是不会移动内存的， 因此， 这个非常容易产生碎片， 导致内存不够用， 因此， 内存的压缩这个时候就会被启用。 增加这个参数是个好习惯
-XX:CMSFullGCsBeforeCompaction：由于并发收集器不对内存空间进行压缩、整理，所以运行一段时间以后会产生“碎片”，使得运行效率降低。此值设置运行多少次GC以后对内存空间进行压缩、整理。
-XX:+UseFastAccessorMethods 原始类型的快速优化
XX:SurvivorRatio=65536决定了新生代中eden与survivor的空间比例是65536：1，这里设置为65536的目的是不使用survivor的空间
-XX:MaxTenuringThreshold=0：设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概论。
-XX:CMSInitiatingOccupancyFraction=70 CMS堆上， 使用70％后开始CMS收集。
-XX:SoftRefLRUPolicyMSPerMB=0是测量一个软引用存活的时间指标，用于使heap中的可用空间达到规定数量。默认值为每兆1000毫秒。这可理解为，对于heap中每兆大小的可用空间而言，一个软引用有1秒的存活时间（在最后一个强引用的对象被回收后）。这个1秒的估算已非常接近真实状态了
　　由于Tocmat6存在一个BUG，以上的配置会引起JVM产生大量的FULL GC，在Tomcat一启动的时候就会FULL GC。解决的办法是在server.xml中增加如下项即可解决
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" gcDaemonProtection="false"/>