Tomcat配置优化

Tomcat配置优化
一、Tomcat并发线程优化
编辑tomcat目录下conf/server.xml文件
修改添加
<Executor
name="tomcatThreadPool"
namePrefix="catalina-exec-"
maxThreads="10000"
minSpareThreads="1000"/>

<Connector
executor="tomcatThreadPool"
port="8080"
protocol="HTTP/1.1"
maxThreads="10000"
<!--maxProcessors - 最大连接线程数，即：并发处理的最大请求数，默认值为75。（用于Tomcat4中）-->
minSpareThreads="1000"
<!--minSpareThreads - 最小空闲线程数，Tomcat初始化时创建的线程数 -->
maxSpareThreads="1000"
<!--maxSpareThreads - 一旦创建的线程超过这个值，Tomcat就会关闭不再需要的socket线程。-->
acceptCount="15000"
<!--acceptCount - 指定当所有可以使用的处理请求的线程数都被使用时，可以放到处理队列中的请求数，超过这个数的请求将不予处理 -->
connectionTimeout="30000"
enableLookups="false"
<!--当web应用程序向要记录客户端的信息时，它也会记录客户端的IP地址或者通过域名服务器查找机器名 转换为IP地址。DNS查询需要占用网络，并且包括可能从很多很远的服务器或者不起作用的服务器上去获取对应的IP的过程，这样会消耗一定的时间。false表示禁用-->
redirectPort="8443"
URIEncoding="UTF-8"/>

二、Tomcat jvm虚拟机内存优化
编辑tomcat目录下bin/catalina.sh文件
在此位置添加
# OS specific support. $var _must_ be set to either true or false.
JAVA_OPTS="-server
-Xms6144M
-Xmx6144M
-Xmn2048M
-XX:PermSize=512M
-XX:MaxPermSize=512M
-XX:SurvivorRatio=65536
-XX:MaxTenuringThreshold=0
-Xnoclassgc
-XX:+DisableExplicitGC
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:+UseCMSCompactAtFullCollection
-XX:CMSFullGCsBeforeCompaction=0
-XX:+CMSClassUnloadingEnabled
-XX:-CMSParallelRemarkEnabled
-XX:CMSInitiatingOccupancyFraction=90
-XX:SoftRefLRUPolicyMSPerMB=0"

各参数解析：
-server 如果不配置该参数，JVM会根据应用服务器硬件配置自动选择不同模式，server模式启动比较慢，但是运行期速度得到了优化，适合于服务器端运行的JVM。

-Xmx 设置java heap的最大值，默认是机器物理内存的1/4。这个值决定了最多可用的Java堆内存：分配过少就会在应用中需要大量内存作缓存或者临时对象时出现OOM（Out Of Memory）的问题；如果分配过大，那么就会因PermSize过小而引起的另外一种Out Of Memory。所以如何配置还是根据运行过程中的分析和计算来确定，如果不能确定还是采用默认的配置。

-Xms 设置Java堆初始化时的大小，默认情况是机器物理内存的1/64。这个主要是根据应用启动时消耗的资源决定，分配少了申请起来会降低运行速度，分配多了也浪费

-Xmn 直接设置青年代大小。整个JVM可用内存大小=青年代大小?+?老年代大小?+?持久代大小?。持久代一般固定大小为64m，所以增大年轻代后，将会减小老年代大小。此值对系统性能影响较大，Sun官方推荐配置为整个堆的3/8

-XX:PermSize 初始化永久内存区域大小。永久内存区域全称是Permanent?Generation?space，是指内存的永久保存区域，程序运行期不对PermGen?space进行清理，所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGen space错误。 这种错误常见在web服务器对JSP进行pre compile的时候。 如果你的WEB APP下用了大量的第三方jar，其大小超过了jvm默认的PermSize大小(4M)那么就会产生此错误信息了

-XX:MaxPermSize 设置永久内存区域最大大小。

-XX:SurvivorRatio 设置年轻代中Eden区与Survivor区的大小比值。设置为4，则两个Survivor区与一个Eden区的比值为2:4，一个Survivor区占整个年轻代的1/6。越大的survivor空间可以允许短期对象尽量在年青代消亡；如果Survivor空间太小，Copying收集将直接将其转移到老年代中，这将加快老年代的空间使用速度，引发频繁的完全垃圾回收。

-XX:MaxTenuringThreshold 设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入老年代。对于老年代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象在年轻代的存活时间，增加在年轻代即被回收的概率。

-Xnoclassgc 这个选项用来取消系统对特定类的垃圾回收。它可以防止当这个类的所有引用丢失之后，这个类仍被引用时不会再一次被重新装载，因此这个选项将增大系统堆内存的空间。禁用类垃圾回收，性能会高一点

-XX:+DisableExplicitGC 禁止java程序中的full gc,如System.gc()的调用。最好加上防止程序在代码里误用了，对性能造成冲击。

-XX:+UseParNewGC 指定在New Generation?使用parallel collector,是UseParallelGC的gc的升级版本,有更好的性能或者优点,可以和CMS gc一起使用

-XX:+UseConcMarkSweepGC 指定在 老年代 使用 concurrent cmark sweep gc。gc thread 和 app thread 并行 ( 在 init-mark 和 remark 时 pause app thread)。app pause 时间较短 , 适合交互性强的系统 , 如 web server。它可以并发执行收集操作，降低应用停止时间，同时它也是并行处理模式，可以有效地利用多处理器的系统的多进程处理。

-XX:+UseCMSCompactAtFullCollection 打开对老年代的压缩。可能会影响性能，但是可以消除碎片,在FULL GC的时候，压缩内存，CMS是不会移动内存的，因此，这个非常容易产生碎片，导致内存不够用。因此，内存的压缩这个时候就会被启用。增加这个参数是个好习惯

-XX:CMSFullGCsBeforeCompaction=0 由于并发收集器不对内存空间进行压缩、整理，所以运行一段时间以后会产生“碎片”，使得运行效率降低。此值设置运行多少次GC以后对内存空间进行压缩、整理。

-XX:+CMSClassUnloadingEnabled 使CMS收集持久代的类，而不是fullgc

-XX:-CMSParallelRemarkEnabled 在使用 UseParNewGC 的情况下 , 尽量减少 mark 的时间

-XX:CMSInitiatingOccupancyFraction=90
说明老年代到百分之多少满的时候开始执行对老年代的并发垃圾回收（CMS），这个参数设置有很大技巧
基本上满足公式： (Xmx-Xmn)*(100-CMSInitiatingOccupancyFraction)/100>=Xmn
时就不会出现promotion failed。在我的应用中Xmx是6000，Xmn是500，那么Xmx-Xmn是5500兆，也就是老年代有5500兆
CMSInitiatingOccupancyFraction=90说明老年代到90%满的时候开始执行对老年代的并发垃圾回收（CMS），这时还剩10%的空间是5500*10%=550兆
所以即使Xmn（也就是年轻代共500兆）里所有对象都搬到老年代里，550兆的空间也足够了，所以只要满足上面的公式，就不会出现垃圾回收时的promotion failed
如果按照Xmx=2048,Xmn=768的比例计算，则CMSInitiatingOccupancyFraction的值不能超过40，否则就容易出现垃圾回收时的promotion failed。

-XX:SoftRefLRUPolicyMSPerMB=0
相对于客户端模式的虚拟机（-client选项），当使用服务器模式的虚拟机时（-server选项），对于软引用（soft reference）的清理力度要稍微差一些。
可以通过增大-XX:SoftRefLRUPolicyMSPerMB来降低收集频率。默认值是 1000，也就是说每秒一兆字节。Soft reference在虚拟机中比在客户集中存活的更长一些。
其清除频率可以用命令行参数