tomcat服务二---tomcat调优

一、tomcat的基本原理

Tomcat服务器的启动是基于一个server.xml文件的，Tomcat启动的时候首先会启动一个Server，Server里面就会启动Service，Service里面就会启动多个"Connector(连接器)"，每一个连接器都在等待客户机的连接，当有用户使用浏览器去访问服务器上面的web资源时，首先是连接到Connector(连接器)，Connector(连接器)是不处理用户的请求的，而是将用户的请求交给一个Engine(引擎)去处理，Engine(引擎)接收到请求后就会解析用户想要访问的Host，然后将请求交给相应的Host，Host收到请求后就会解析出用户想要访问这个Host下面的哪一个Web应用,一个web应用对应一个Context。

二、tomcat调优

1、内存调优，在canalina.sh中写入如下内容

export JAVA_OPTS="-server -Xms4096m -Xmx4096m -XX:+PrintHeapAtGC -Xloggc:/usr/local/tomcat_front/logs/gc.log -XX:+PrintGCTimeStamps -XX:+TraceClassLoading -XX:+TraceClassUnloading -XX:+PrintReferenceGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/local/tomcat_front/logs/front1.bin"

参数解释：

-server：运行jdk的server版本

-Xms：java虚拟机初始化时堆的内存大小，一般配置Xmx配置为相同的值，这样的好处是GC不必再为扩展内存空间而消耗性能

-Xmx：java虚拟机可使用堆的最大内存

-XX:+PrintHeapAtGC  

-Xloggc:/usr/local/tomcat_front/logs/gc.log

-XX:+PrintGCTimeStamps

-XX:+TraceClassLoading

-XX:+TraceClassUnloading

-XX:+PrintReferenceGC

-XX:+HeapDumpOnOutOfMemmoryError

-XX:HeapDumpPath=/usr/local/tomcat_front/logs/front1.bin

除了这些参数之外，还可以记录其他参数，可参考jvm参数的配置。

设置成功后，可以使用jdk自带的工具进行验证，在JAVA_HOME/bin目录下运行

$jps

$jump -heap  进程号

2、连接器Connector调优，在server.xml中加入如下内容

<Connector port="8080"
        protocol="HTTP/1.1"
        connectionTimeout="20000"    ##超时时间，毫秒，这里是20秒
        redirectPort="443"
        maxThreads="3000"          ##最大线程数
        minSpareThreads="20"   ##最小空闲线程数，这里是一直会运行的线程
        acceptCount="1000"        ##接收的队列数
        enableLookups="false"    ##关闭dns解析，减少性能损耗
        server="None"              
        URIEncoding="UTF-8"  
        compression="on"         ##开启压缩
    compressionMinSize="2048"     ##最小压缩文件的大小
    noCompressionUserAgents="gozilla,traviata"     ##这俩种浏览器下不压缩
    compressableMimeType="text/html,text/xml,text/javascript,application/x-javascript,application/javascript,text/css,text/plain"  ##压缩的格式
      />
3、线程池

Executor代表了一个线程池，可以在Tomcat组件之间共享。使用线程池的好处在于减少了创建销毁线程的相关消耗，而且可以提高线程的使用效率。要想使用线程池，首先需要在 Service标签中配置 Executor，如下：

<Service name="Catalina">  
      
      <Executor name="tomcatThreadPool"   
             namePrefix="catalina-exec-"   
             maxThreads="1000"   
             minSpareThreads="100"  
             maxIdleTime="60000"  
             maxQueueSize="Integer.MAX_VALUE"  
             prestartminSpareThreads="false"  
             threadPriority="5"  
             className="org.apache.catalina.core.StandardThreadExecutor"/>  
      ....  

 其中，
name：线程池名称，用于 Connector中指定。

namePrefix：所创建的每个线程的名称前缀，一个单独的线程名称为 namePrefix+threadNumber。

maxThreads：池中最大线程数。

minSpareThreads：活跃线程数，也就是核心池线程数，这些线程不会被销毁，会一直存在。

maxIdleTime：线程空闲时间，超过该时间后，空闲线程会被销毁，默认值为6000（1分钟），单位毫秒。

maxQueueSize：在被执行前最大线程排队数目，默认为Int的最大值，也就是广义的无限。除非特殊情况，这个值不需要更改，否则会有请求不会被处理的情况发生。

prestartminSpareThreads：启动线程池时是否启动 minSpareThreads部分线程。默认值为false，即不启动。

threadPriority：线程池中线程优先级，默认值为5，值从1到10。

className：线程池实现类，未指定情况下，默认实现类为org.apache.catalina.core.StandardThreadExecutor。如果想使用自定义线程池首先需要实现org.apache.catalina.Executor接口。

程池配置完成后需要在 Connector中指定：
  <Connector executor="tomcatThreadPool"  
      ... 

三、填坑心得（转发）

http://www.cnblogs.com/hucn/p/3572384.html

我遇到这样的问题，本地部署时抛出异常java.lang.OutOfMemoryError：GC overhead limit exceeded导致服务起不来，查看日志发现加载了太多资源到内存，本地的性能也不好，gc时间消耗的较多。解决这种问题两种方法是，增加参数，-XX:-UseGCOverheadLimit，关闭这个特性，同时增加heap大小，-Xmx1024m。坑填了，but why？

OOM大家都知道，就是JVM内存溢出了，那GC overhead limit exceed呢？

GC overhead limt exceed检查是Hotspot VM 1.6定义的一个策略，通过统计GC时间来预测是否要OOM了，提前抛出异常，防止OOM发生。Sun 官方对此的定义是：“并行/并发回收器在GC回收时间过长时会抛出OutOfMemroyError。过长的定义是，超过98%的时间用来做GC并且回收了不到2%的堆内存。用来避免内存过小造成应用不能正常工作。“

听起来没啥用...预测OOM有啥用？起初开来这玩意只能用来Catch住释放内存资源，避免应用挂掉。后来发现一般情况下这个策略不能拯救你的应用，但是可以在应用挂掉之前做最后的挣扎，比如数据保存或者保存现场（Heap Dump）。

而且有些时候这个策略还会带来问题，比如加载某个大的内存数据时频繁OOM。

假如你也生产环境中遇到了这个问题，在不知道原因时不要简单的猜测和规避。可以通过-verbose:gc -XX:+PrintGCDetails看下到底什么原因造成了异常。通常原因都是因为old区占用过多导致频繁Full GC，最终导致GC overhead limit exceed。如果gc log不够可以借助于JProfile等工具查看内存的占用，old区是否有内存泄露。分析内存泄露还有一个方法-XX:+HeapDumpOnOutOfMemoryError，这样OOM时会自动做Heap Dump，可以拿MAT来排查了。还要留意young区，如果有过多短暂对象分配，可能也会抛这个异常。

日志的信息不难理解，就是每次gc时打条日志，记录GC的类型，前后大小和时间。举个例子。

33.125: [GC [DefNew: 16000K->16000K(16192K), 0.0000574 secs][Tenured: 2973K->2704K(16384K), 0.1012650 secs] 18973K->2704K(32576K), 0.1015066 secs]

100.667:[Full GC [Tenured: 0K->210K(10240K), 0.0149142 secs] 4603K->210K(19456K), [Perm : 2999K->2999K(21248K)], 0.0150007 secs] 

GC和Full GC代表gc的停顿类型，Full GC代表stop-the-world。箭头两边是gc前后的区空间大小，分别是young区、tenured区和perm区，括号里是该区的总大小。冒号前面是gc发生的时间，单位是秒，从jvm启动开始计算。DefNew代表Serial收集器，为Default New Generation的缩写，类似的还有PSYoungGen，代表Parallel Scavenge收集器。这样可以通过分析日志找到导致GC overhead limit exceeded的原因，通过调节相应的参数解决问题。

文中涉及到的名词解释，

Eden Space：堆内存池，大多数对象在这里分配内存空间。

Survivor Space：堆内存池，存储在Eden Space的gc中存活下来的对象。

Tenured Generation：堆内存池，存储Survivor Space中存活过几次gc的对象。

Permanent Generation：非堆空间，存储的是class和method对象。

Code Cache：非堆空间，JVM用来存储编译和存储native code。