记一次JVM调优

前情：8月1日到新公司入职，到职第一天上级就分配了任务，优化OA。
OA目前的情况：运行一段时间后就会很卡，打开流程或表单一直处于刷新状态，只有重启tomcat服务后才能恢复正常。开始想从oracle数据库入手，确认是不是oracle数据量太大未做优化导致的，导出awr报表做分析，结果实在是看不太懂，只好放弃，转从tomcat入手。

tomcat服务器信息：

系统版本 CPU核数 内存容量 Red Hat 4.8.5-4 20 64G

jdk信息：

version SE RunTIme Environment HotSpot 1.6.0-31 build 1.6.0_31-b04 64-Bit Server VM (build 20.6-b01, mixed mode)

tomcat信息：

版本 6.0.35

公司目前在职员工8000人左右，同时在线人数2500人左右。
首先查看原来的JVM设置：

JAVA_OPTS="-server -Xms16000m -Xmx16000m -XX:PermSize=1024M -XX:MaxNewSize=1024m -XX:MaxPermSize=1024m -Djava.awt.headless=true "

可以看出配置了堆的大小16000M，大约15.5G左右，最大年轻代1G，永久堆内存1G，我们通过VisualVM可以更直观的看到整个内存的分配情况：

注：这是后面模拟当时的服务器信息的截图，调优时没有截图。

通过查询资料及百度然后对JVM做了第一次优化：

JAVA_OPTS="-server -Xms16000M -Xmx16000M -Xss256k -XX:NewSize=2048M -XX:MaxNewSize=2304M -XX:PermSize=2048M-XX:MaxPermSize=2304M  -XX:+AggressiveOpts -XX:+UseBiasedLocking -XX:+DisableExplicitGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=31 -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly-Duser.timezone=Asia/Shanghai -Djava.awt.headless=true-Dcom.sun.management.jmxremote -Djava.rmi.server.hostname=192.168.0.99 -Dcom.sun.management.jmxremote.port=8010 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false"

xms和xmx没有做改动，还是16000M，增加了xss:每个线程的堆栈大小,加大了年轻代的内存，设置垃圾回收机制CMS，其他参数就不一一解释了，我们看看优化后的情况：

可以看到eden区明显的增大了,old区缩小了一些，perm gen（永久代）有增加，下面多了一列Histogram，这是-XX:MaxTenuringThreshold=31 参数设置后的效果，表示survivor的存活生命周期。这次优化后并没有达到效果，下午访问量大的时候old区很快就满了，然后OA打开流程或表单一直在刷新，要保存的数据也没法保存。

虽然失败了，但是经错这次优化发现了OA访问卡死的原因：old即年老代内存满了，触发了Full GC，然后就是大家说的stop the world，所有线程等待Full GC完成后才能重新访问，自然OA无法访问甚至直接客户端浏览器卡死。既然知道原因了那就对症下药。又是一通百度查寻各种网上的方案。
既然是年老代满了那么就加大年老代不就行了，通过事实验证只是加大年老代是不行的，因为总有一天它还是会满的，那有没有方案能在它满之前就先执行垃圾回收，释放内存呢？答案是肯定可以的。通过配置-XX:CMSInitiatingOccupancyFraction=73可以设置当年老区满多少的时候进行垃圾回收，这里我设置的73%，并不时随便设置的，通过这个公式可以计算出来：

CMSInitiatingOccupancyFraction <=((Xmx-Xmn)-(Xmn-Xmn/(SurvivorRatior+2)))/(Xmx-Xmn)*100

查询资料还发现，可以通过加大survivor区来达到一些对象在未到达年老代就被回收掉，可以通过设置-XX:SurvivorRatio=3参数来达到效果，然后再一次进行优化：

JAVA_OPTS="-server -Xms20480M -Xmx20480M -Xss256k -XX:NewSize=5120M -XX:MaxNewSize=5120M -XX:PermSize=256M-XX:MaxPermSize=256M  -XX:SurvivorRatio=3-XX:+AggressiveOpts -XX:+UseBiasedLocking -XX:+DisableExplicitGC -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:CMSFullGCsBeforeCompaction=0-XX:+CMSClassUnloadingEnabled-XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly-XX:CMSInitiatingOccupancyFraction=73-XX:SoftRefLRUPolicyMSPerMB=0-verbose:gc -XX:+PrintGCTimeStamps -XX:+PrintGCDetails -Xloggc:/usr/local/tomcat/temp/gc.log-Duser.timezone=Asia/Shanghai -Djava.awt.headless=true-Dcom.sun.management.jmxremote -Djava.rmi.server.hostname=192.168.0.99 -Dcom.sun.management.jmxremote.port=8010 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false"

这次显示增大了整个堆内存，然后增加了survivor的比例，设置了CMS垃圾回收在73%时自动回收，这时服务器的最终效果如下：

通过设置-Xloggc:/usr/local/tomcat/temp/gc.log，可以查看到GC的相关日志。
这次优化后跟踪了2天，占时没出现old区满的情况，当达到73%时会自动执行垃圾回收，由于是并行的，所以对整个OA的访问并不影响。这样的优化应该还有改进的地方，后面我会继续跟踪并优化。