Tomcat调优总结（Tomcat自身优化、Linux内核优化、JVM优化）

Tomcat自身的调优是针对conf/server.xml中的几个参数的调优设置。首先是对这几个参数的含义要有深入而清楚的理解。以tomcat8.5为例，讲解参数。

同时也得认识到一点，tomcat调优也受制于linux内核。linux内核对tcp链接也有几个参数能够调优。

所以咱们能够将tomcat调优分为linux内核优化、java虚拟机调优和tomcat自身的优化。

 

 1、Tomcat自身优化

1. maxThreads ：tomcat建立的最大线程数，也就是同时处理的请求最大并发数。默认值是200

官网：The maximum number of request processing threads to be created by this Connector, which therefore determines the maximum number of simultaneous requests that can be handled. If not specified, this attribute is set to 200. If an executor is associated with this connector, this attribute is ignored as the connector will execute tasks using the executor rather than an internal thread pool. Note that if an executor is configured any value set for this attribute will be recorded correctly but it will be reported (e.g. via JMX) as -1 to make clear that it is not used.

 maxThreads如何配置（转）

通常的服务器操做都包括量方面：1计算（主要消耗cpu），2等待（io、数据库等）

第一种极端状况，若是咱们的操做是纯粹的计算，那么系统响应时间的主要限制就是cpu的运算能力，此时maxThreads应该尽可能设的小，下降同一时间内争抢cpu的线程个数，能够提升计算效率，提升系统的总体处理能力。

第二种极端状况，若是咱们的操做纯粹是IO或者数据库，那么响应时间的主要限制就变为等待外部资源，此时maxThreads应该尽可能设的大，这样才能提升同时处理请求的个数，从而提升系统总体的处理能力。此状况下由于tomcat同时处理的请求量会比较大，因此须要关注一下tomcat的虚拟机内存设置和linux的open file限制。

我在测试时遇到一个问题，maxThreads我设置的比较大好比3000，当服务的线程数大到必定程度时，通常是2000出头，单次请求的响应时间就会急剧的增长，

百思不得其解这是为何，四处寻求答案无果，最后我总结的缘由多是cpu在线程切换时消耗的时间随着线程数量的增长愈来愈大，

cpu把大多数时间都用来在这2000多个线程直接切换上了，固然cpu就没有时间来处理咱们的程序了。

之前一直简单的认为多线程=高效率。。其实多线程自己并不能提升cpu效率，线程过多反而会下降cpu效率。

当cpu核心数<线程数时，cpu就须要在多个线程直接来回切换，以保证每一个线程都会得到cpu时间，即一般咱们说的并发执行。

因此maxThreads的配置绝对不是越大越好。

现实应用中，咱们的操做都会包含以上两种类型（计算、等待），因此maxThreads的配置并无一个最优值，必定要根据具体状况来配置。

最好的作法是：在不断测试的基础上，不断调整、优化，才能获得最合理的配置。

2. acceptCount：当tomcat的线程数达到了最大时，接收排队的最大请求个数。默认值为100

官网：the maximum queue length for incoming connection requests when all possible request processing threads are in use. Any requests received when the queue is full will be refused. The default value is 100.

 

maxThreads与acceptCount这两个值是如何起做用的呢？

 

状况1：接受一个请求，此时tomcat起动的线程数没有到达maxThreads，tomcat会起动一个线程来处理此请求。

 

状况2：接受一个请求，此时tomcat起动的线程数已经到达maxThreads，tomcat会把此请求放入等待队列，等待空闲线程。

 

状况3：接受一个请求，此时tomcat起动的线程数已经到达maxThreads，等待队列中的请求个数也达到了acceptCount，此时tomcat会直接拒绝这次请求，返回connection refused。

对于第3种状况，在看过一篇分析connection timeout问题产生的缘由后，等待队列的请求个数这个值多是由acceptCount参数决定，也有可能由linux内核参数net.core.somaxconn决定。

 

 

关联:我在网上看来一篇文章写分析linux上TCP connection timeout的缘由，这篇文章中提到一个内核参数 net.core.somaxconn。

我就想tomcat的acceptCount与net.core.somaxconn究竟是什么关系呢。 

我作了一个实验，

1. 我将tomcat的acceptCount设置为3000 ，net.core.somaxconn设置为8192

那么我用ss -lt 指令查看在tomcat起的端口上的send_q值是3000  可见这是acceptCount的值。

2.我将tomcat的acceptCount设置为10000，net.core.somaxconn设置为8192

一样用ss -lt指令查看在tomcat起的端口上的send_q值是8192,可见这是somaxconn的值。

 因此，我总结的是，acceptCount设置的值要通常小于net.core.somaxconn这个参数，这样acceptCount的值才会起做用。net.core.somaxconn 这个参数默认值是128 ，因此须要改这个参数值。后面再介绍改这个值的方法。

 

acceptCount如何配置？（转）

我通常是设置的跟maxThreads同样大，这个值应该是主要根据应用的访问峰值与平均值来权衡配置的。

若是设的较小，能够保证接受的请求较快相应，可是超出的请求可能就直接被拒绝

若是设的较大，可能就会出现大量的请求超时的状况，由于咱们系统的处理能力是必定的。

3. maxConnections

官网：

The maximum number of connections that the server will accept and process at any given time. When this number has been reached, the server will accept, but not process, one further connection. This additional connection be blocked until the number of connections being processed falls below maxConnections at which point the server will start accepting and processing new connections again. Note that once the limit has been reached, the operating system may still accept connections based on the acceptCount setting. The default value varies by connector type. For NIO and NIO2 the default is 10000. For APR/native, the default is 8192.

Note that for APR/native on Windows, the configured value will be reduced to the highest multiple of 1024 that is less than or equal to maxConnections. This is done for performance reasons.
If set to a value of -1, the maxConnections feature is disabled and connections are not counted.

Tomcat容许的同时存在的最大链接数

 acceptCount、maxConnections是tcp层相关的参数。

4.connectionTimeOut ：connectionTimeOut=10000是说创建一个socket链接后，若是一直没有收到客户端的FIN，也没有数据过来，那么此链接也必须等到10s后，才能被超时释放，我理解是tomcat就直接释放这个链接。以毫秒为单位，server.xml默认设置是20秒。

官网：The number of milliseconds this Connector will wait, after accepting a connection, for the request URI line to be presented. Use a value of -1 to indicate no (i.e. infinite) timeout. The default value is 60000 (i.e. 60 seconds) but note that the standard server.xml that ships with Tomcat sets this to 20000 (i.e. 20 seconds). Unless disableUploadTimeout is set to false, this timeout will also be used when reading the request body (if any).

 

 

修改方法：

  vi server.xml 打开server.xml文件

将 

<!-- <Executor name="tomcatThreadPool" namePrefix="catalina-exec-" maxThreads="150" minSpareThreads="4"/> -->
修改成：
 <Executor name="tomcatThreadPool" namePrefix="catalina-exec-" maxThreads="1500" minSpareThreads="50" prestartminSpareThreads="true"/>

将

<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />
修改成

 <Connector executor ="tomcatThreadPool" port="8009" protocol="org.apache.coyote.http11.Http11Nio2Protocol" connectionTimeout="20000" maxConnections="10000" redirectPort="8443" acceptCount="1500"/>

下面的图为TCP三次握手与accept交互

 

 

 SYN队列称为半链接队列，由内核参数 net.ipv4.tcp_max_syn_backlog 设置.

Accept队列称为彻底链接队列，三次握手已经完成,但还未被应用层接收(accept),但也处于ESTABLISHED状态。队列长度由listen的backlog参数和内核的 net.core.somaxconn 参数共同决定。由listen()函数的第二个参数 backlog 指定，内核硬限制由 net.core.somaxconn 限制，即队列长度实际的值由min(backlog,somaxconn) 来决定

客户端使用connect向服务器发送TCP链接，三次握手就发生了。当1.1步骤 客户端首先发送SYN到达服务端后，内核会把链接信息放到SYN队列中，同时回一个SYN+ACK包给客户端。一段时间后，客户端再次发来ACK包后，内核会把链接从SYN队列中取出，再把这个链接放到ACCEPT队列中。应用服务器调用accept时，其实就是直接从ACCEPT队列中取出已经创建成功的链接套接字。

 

还有一张图是TCP握手创建链接的流程和队列

 

 Tomcat原理概要

Tomcat大体分为两个部分，Connector组件及Container组件。Connector组件负责控制入口链接，并关联着一个Executor。Container负责Servlet容器的实现，Executor负责具体的业务逻辑，如Servlet的执行。一个请求到达服务器后，通过如下关键几步，参见下图：

1. OS与客户端握手并创建链接，并将创建的链接放入完成队列，不妨叫Acceptor Queque。这个队列的长度就是Connector的acceptCount值。

2. Tomcat中的acceptor线程，不断从Acceptor Queque中获取链接。

3. Acceptor Queque队列中没有链接，Acceptor线程继续监视

4. Acceptor Queque队列中有新链接，Acceptor线程将检查当前的链接数是否超过了maxConnections

5. 若是超过maxConnections，则阻塞。直到链接数小于maxConnections，acceptor线程将请求交由Executor负责执行。

6. Executor将分配worker线程来处理请求数据的读取，处理（servlet的执行）以及响应。

   acceptCount

   acceptCount 其实是Bind Socket时候传递的backlog值，在linux平台下含义是已经创建链接尚未被应用获取的链接队列最大长度。此时，若是请求个数达到了acceptCount，新进的请求将抛出refuse connection.

 

2、Linux内核参数优化

1. linux系统对当前用户的单一进程同时可打开的文件数量的限制

 查看系统容许当前用户进程打开的文件数量的限制： ulimit -u     默认值为1024 。便是Linux操做系统对一个进程打开的文件句柄数量的限制

对于想支持更高数量的TCP并发链接的通信处理程序，就必须修改Linux对当前用户的进程同时打开的文件数量的软限制(soft limit)和硬限制(hardlimit)。其中软限制是指Linux在当前系统可以承受的范围内进一步限制用户同时打开的文件数；硬限制则是根据系统硬件资源情况(主要是系统内存)计算出来的系统最多可同时打开的文件数量。一般软限制小于或等于硬限制。

修改方法：

 sudo vi /etc/security/limits.conf 

增长以下：

prouser  soft   nofile 65536
prouser  hard nofile 65536

prouser  soft  nproc 65536

prouser hard nproc 65536

修改完后保存此文件。

 

nproc是操做系统级别对每一个用户建立的进程数的限制

2.Linux网络内核对TCP链接的有关限制

修改方法：

 

sudo vi /etc/sysctl.conf

 

增长以下：

 

net.ipv4.tcp_tw_reuse = 1 

net.ipv4.tcp_tw_recycle = 1 
net.ipv4.tcp_fin_timeout = 30 
net.ipv4.ip_local_port_range = 10000 65000 
net.ipv4.tcp_max_syn_backlog = 8192 
net.ipv4.tcp_max_tw_buckets = 10000

net.core.somaxconn=8192      accept队列的长度跟这个参数有关

 

sudo /sbin/sysctl -p

 

实时生效

 

3、JVM调优

JAVA_OPTS="$JAVA_OPTS -server -Xmn2000m -Xms4000m -Xmx4000m -XX:PermSize=128m -XX:+UseConcMarkSweepGC -XX:MaxPermSize=512m -Djuli-logback.configurationFile=file:$CATALINA_HOME/conf/logback.xml"

默认值:

<!--
 <Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
 maxThreads="150" minSpareThreads="4"/>
 -->

修改成:

<Executor
 name="tomcatThreadPool"
 namePrefix="catalina-exec-"
 maxThreads="500"
 minSpareThreads="30"
 maxIdleTime="60000"
 prestartminSpareThreads = "true"
 maxQueueSize = "100"
/>

参数解释：

maxThreads：最大并发数，默认设置 200，通常建议在 500 ~ 800，根据硬件设施和业务来判断
minSpareThreads：Tomcat 初始化时建立的线程数，默认设置 25
maxIdleTime：若是当前线程大于初始化线程，那空闲线程存活的时间，单位毫秒，默认60000=60秒=1分钟。
prestartminSpareThreads：在 Tomcat 初始化的时候就初始化 minSpareThreads 的参数值，若是不等于 true，minSpareThreads 的值就没啥效果了
maxQueueSize：最大的等待队列数，超过则拒绝请求