成都有实力的网站建设,电子商务网站开发的意义,品牌建设的目标,杭州市规划建设网站Tomcat自身的调优是针对conf/server.xml中的几个参数的调优设置。首先是对这几个参数的含义要有深刻而清楚的理解。以tomcat8.5为例#xff0c;讲解参数。
同时也得认识到一点#xff0c;tomcat调优也受制于linux内核。linux内核对tcp连接也有几个参数可以调优。
因此可以将…Tomcat自身的调优是针对conf/server.xml中的几个参数的调优设置。首先是对这几个参数的含义要有深刻而清楚的理解。以tomcat8.5为例讲解参数。
同时也得认识到一点tomcat调优也受制于linux内核。linux内核对tcp连接也有几个参数可以调优。
因此可以将tomcat调优分为
linux内核优化java虚拟机调优tomcat自身优化
1 tomcat自身优化
1.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. 1.1.1 maxThreads如何配置
一般的服务器操作都包括量方面
计算主要消耗cpu等待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的配置并没有一个最优值一定要根据具体情况来配置。
最好的做法是在不断测试的基础上不断调整、优化才能得到最合理的配置。
1.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启动的线程数没有到达maxThreadstomcat会起动一个线程来处理此请求。
情况2接受一个请求此时tomcat起动的线程数已经到达maxThreadstomcat会把此请求放入等待队列等待空闲线程。
情况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设置为10000net.core.somaxconn设置为8192
同样用ss -lt指令查看在tomcat起的端口上的send_q值是8192,可见这是somaxconn的值。
所以acceptCount设置的值要一般小于net.core.somaxconn这个参数这样acceptCount的值才会起作用。net.core.somaxconn 这个参数默认值是128 所以需要改这个参数值。后面再介绍改这个值的方法。
1.2.1 acceptCount如何配置
一般是设置的跟maxThreads一样大这个值应该是主要根据应用的访问峰值与平均值来权衡配置的。
如果设的较小可以保证接受的请求较快相应但是超出的请求可能就直接被拒绝如果设的较大可能就会出现大量的请求超时的情况因为我们系统的处理能力是一定的。
1.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. maxConnections是指Tomcat允许的同时存在的最大连接数。 acceptCount、maxConnections是tcp层相关的参数。 1.4 connectionTimeOut
connectionTimeOut10000是说建立一个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 nametomcatThreadPool namePrefixcatalina-exec-maxThreads150 minSpareThreads4/--
修改为Executor nametomcatThreadPool namePrefixcatalina-exec-maxThreads1500 minSpareThreads50 prestartminSpareThreadstrue/将Connector port8080 protocolHTTP/1.1 connectionTimeout20000 redirectPort8443 /
修改为Connector executor tomcatThreadPool port8009 protocolorg.apache.coyote.http11.Http11Nio2Protocol connectionTimeout20000 maxConnections10000 redirectPort8443 acceptCount1500/下面的图为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队列中同时回一个SYNACK包给客户端。一段时间后客户端再次发来ACK包后内核会把连接从SYN队列中取出再把这个连接放到ACCEPT队列中。应用服务器调用accept时其实就是直接从ACCEPT队列中取出已经建立成功的连接套接字。
还有一张图是TCP握手建立连接的流程和队列 1.5 Tomcat原理概要
Tomcat大致分为两个部分Connector组件及Container组件。Connector组件负责控制入口连接并关联着一个Executor。Container负责Servlet容器的实现Executor负责具体的业务逻辑如Servlet的执行。一个请求到达服务器后经过以下关键几步参见下图 OS与客户端握手并建立连接并将建立的连接放入完成队列不妨叫Acceptor Queque。这个队列的长度就是Connector的acceptCount值。 Tomcat中的acceptor线程不断从Acceptor Queque中获取连接。 Acceptor Queque队列中没有连接Acceptor线程继续监视 Acceptor Queque队列中有新连接Acceptor线程将检查当前的连接数是否超过了maxConnections 如果超过maxConnections则阻塞。直到连接数小于maxConnectionsacceptor线程将请求交由Executor负责执行。 Executor将分配worker线程来处理请求数据的读取处理servlet的执行以及响应。
acceptCount
acceptCount 实际上是Bind Socket时候传递的backlog值在linux平台下含义是已经建立连接还没有被应用获取的连接队列最大长度。此时如果请求个数达到了acceptCount新进的请求将抛出refuse connection.
2 Linux内核参数优化
2.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 65536prouser soft nproc 65536prouser hard nproc 65536
修改完后保存此文件。 nproc是操作系统级别对每个用户创建的进程数的限制。 2.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.somaxconn8192 accept队列的长度跟这个参数有关sudo /sbin/sysctl -p
实时生效
3 JVM调优
JAVA_OPTS$JAVA_OPTS -server -Xmn2000m -Xms4000m -Xmx4000m -XX:PermSize128m -XX:UseConcMarkSweepGC -XX:MaxPermSize512m -Djuli-logback.configurationFilefile:$CATALINA_HOME/conf/logback.xml
默认值:
!--Executor nametomcatThreadPool namePrefixcatalina-exec-maxThreads150 minSpareThreads4/--
修改为:
ExecutornametomcatThreadPoolnamePrefixcatalina-exec-maxThreads500minSpareThreads30maxIdleTime60000prestartminSpareThreads truemaxQueueSize 100
/
参数解释
maxThreads最大并发数默认设置 200一般建议在 500 ~ 800根据硬件设施和业务来判断minSpareThreadsTomcat 初始化时创建的线程数默认设置 25maxIdleTime如果当前线程大于初始化线程那空闲线程存活的时间单位毫秒默认6000060秒1分钟。prestartminSpareThreads在 Tomcat 初始化的时候就初始化 minSpareThreads 的参数值如果不等于 trueminSpareThreads 的值就没啥效果了maxQueueSize最大的等待队列数超过则拒绝请求 4 生产环境调优实战
4.1 tomcat 启动慢
在线上环境中我们经常会遇到类似的问题就是tomcat 启动比较慢查看内存和cpu,io都是正常的但是启动很慢有的时候长达几分钟这到底是什么原因导致的
4.1.1 tomcat 获取随机值阻塞
tomcat的启动需要产生session id这个产生需要通过java.security.SecureRandom生成随机数来实现随机数算法使用的是”SHA1PRNG”但这个算法依赖于操作系统的提供的随机数据在linux系统中这个值又依赖于/dev/random 和/dev/urandom
/dev/random :阻塞型读取它就会产生随机数据但该数据取决于熵池噪声当熵池空了对/dev/random 的读操作也将会被阻塞。
/dev/urandom: 非阻塞的随机数产生器它会重复使用熵池中的数据以产生伪随机数据。这表示对/dev/urandom的读取操作不会产生阻塞但其输出的熵可能小于/dev/random的。它可以作为生成较低强度密码的伪随机数生成器不建议用于生成高强度长期密码。我们通过查看java.security 文件(我的java版本是1.8.0_131) 发现依赖的是/dev/random tomcat 启动产生session id 最终依赖的是/dev/random /dev/random 又依赖于熵池
对于熵池百度百科这样写到 Linux内核采用熵来描述数据的随机性。熵entropy是描述系统混乱无序程度的物理量一个系统的熵越大则说明该系统的有序性越差即不确定性越大。在信息学中熵被用来表征一个符号或系统的不确定性熵越大表明系统所含有用信息量越少不确定度越大。计算机本身是可预测的系统因此用计算机算法不可能产生真正的随机数。但是机器的环境中充满了各种各样的噪声如硬件设备发生中断的时间用户点击鼠标的时间间隔等是完全随机的事先无法预测。Linux内核实现的随机数产生器正是利用系统中的这些随机噪声来产生高质量随机数序列。内核维护了一个熵池用来收集来自设备驱动程序和其它来源的环境噪音。理论上熵池中的数据是完全随机的可以实现产生真随机数序列。为跟踪熵池中数据的随机性内核在将数据加入池的时候将估算数据的随机性这个过程称作熵估算。熵估算值描述池中包含的随机数位数其值越大表示池中数据的随机性越好。 那么如何查看熵池 的大小,文件 /proc/sys/kernel/random/entropy_avail 保存着 熵池的大小。/proc/sys/kernel/random/poolsize 保存着熵池的最大容量单位都是bit。
[roothaha cwd]# cat /proc/sys/kernel/random/entropy_avail
146总结
tomcat 启动慢的原因是随机数产生遭到阻塞遭到阻塞的原因是 熵池大小 。
解决方法
1. 更换产生随机数的源(也是tomcat的官方文档的启动比较慢的解决办法)
2. 增大熵池 的值1更换产生随机数的源
因为/dev/urandom 是非阻塞的随机数产生器所以我们可以从这边获取但是生产的随机数的随机性比较低。我们可以在 我们的tomcat启动脚本(catalina.sh)里面添加
JAVA_OPTS$JAVA_OPTS -Djava.security.egdfile:/dev/./urandom或者是更改java的java.security 文件将securerandom.sourcefile:/dev/random
securerandom.sourcefile:/dev/./urandom注意为什么我们这里使用的路径是/dev/./urandom,而不是 /dev/urandom,是因为在java 8之前的版本设置了/dev/urandom 但是实际还是使用/dev/random设置为/dev/./urandom才能正常使用 /dev/urandom 这个bug在java8版本已经修复了如果你是java7版本的话需要按照上面设置java8的话可以不用加 ./。 2增大熵池 的值
要增大熵池 的值首先得你的cpu支持DRNG 特性 如何查看我们的服务器的是否支持DRNG特性
cat /proc/cpuinfo | grep rdrand如果不支持的话那么就只能通过上面的第一种方法来解决了
安装rngd服务(关于rngd服务的介绍)
yum -y install rng-tools
systemctl enable rngd
systemctl start rngd然后我们进行查看我们的熵池 的值,会发现变大了 cat /proc/sys/kernel/random/entropy_avail然后我们启动tomcat 会发现启动速度快很多。
4.1.2 tomcat 需要部署的web应用程序太多
有时候tomcat启动比较慢是因为它需要部署的web应用程序太多但是其中有些应用程序是不需要的比如在webapps下的 doc 、example、ROOT 等等可以将不需要的webapps删除然后再进行发布这些不需要的web不仅会占用资源还有可能是入侵者的入侵对象。如果想并行启动多个web应用程序我们可以Host 的属性 startStopThreads 值设置大于1 但这也取决于我们的服务器是不是多核的。如果是多核的建议调大 startStopThreads 的值但不超过内核数。
4.1.3 tomcat启动内存不足
如果是项目比较大的话使用默认的参数去启动的tomcat是很有可能内存不足的需要设置JVM将内存调整JVM 的最大值和最小值建议是不要相差太大(最好一致.)
在启动脚本catalina.sh加上
JAVA_OPTS-server -Xms1024m -Xmx1024m具体的内存大小根据业务调整。
以上就是解决tomcat 启动慢的问题和解决方案可根据自己的项目情况进行使用。
4.2 Connector 调优
4.2.1 使用arp 连接器
tomcat 可以使用Apache Portable Runtime来提供更高的性能服务。Apache Portable Runtime是一个高度可移植的库是Apache HTTP Server 2.x的核心。APR有许多用途包含高级的io功能(sendfile,epoll,Openssl),系统级别功能(产生随机数系统状态)和进程处理(共享内存NT管道unix套接字)它可以让tomcat成为通用的web服务器让java应用作为一个完整的web服务器更加可行而不是仅仅作为后端的技术。
总结从系统级别来解决异步io的问题提升性能。
apr 连接器需要自己手动安装需要以下组件 APR library (需要手动下载安装) tomcat 8.5 需要 APR 1.2 OpenSSL libraries (需要安装) JNI wrappers for APR used by Tomcat (libtcnative) tomcat 安装包已经提供
4.2.1.1 yum安装(建议)
注意apr安装的版本
yum -y install openssl
yum -y install apr
yum -y install apr-util
yum -y install tomcat-native4.2.1.2 源码安装 4.2.1.2.1 apr源码编译
安装流程https://www.cnblogs.com/zscc/p/9349908.html
1安装依赖并下载apr 包
下载地址 http://archive.apache.org/dist/apr/
yum -y install make gcc gcc-c openssl-devel libtool
cd /tmp wget http://archive.apache.org/dist/apr/apr-1.6.5.tar.gz2解压apr 包
tar -xzf apr-1.6.5.tar.gz cd apr-1.6.53预编译编译安装
./configure --prefix/usr/local/apr
make
make install 4.2.1.2.2 native 安装
1解压native 包 (native 包在tomcat 安装包里面 bin下)
cd tomcat/bin tar -xzf tomcat-native.tar.gz2预编译编译安装
cd tomcat-native*/native ./configure --with-apr/usr/local/apr
make
make install 3添加环境变量
vim /etc/profile
# 添加环境变量
export LD_LIBRARY_PATH$LD_LIBRARY_PATH:/usr/local/apr/lib# 加载变量
source /etc/profile
4.2.1.3 配置apr 连接器
vim ./conf/server.xml# 将 Connector 属性protocol 配置成 apr(org.apache.coyote.http11.Http11AprProtocol)Connector port8080 protocolorg.apache.coyote.http11.Http11AprProtocolconnectionTimeout20000redirectPort8443 /
默认连接器为nio共有三大连接器 org.apache.coyote.http11.Http11NioProtocol 非阻塞nio连接器 org.apache.coyote.http11.Http11Nio2Protocol 非阻塞nio2连接器 org.apache.coyote.http11.Http11AprProtocol APR连接器
重启tomcat 4.2.1.4 APR 测试
tomcat,jvm使用默认配置进行测试使用nio 连接器 共1000次请求100并发 在nio连接器时我多次尝试使用150并发共1000请求去测试发现一直成功不了但是当我使用apr连接时
1100并发 2150 并发 我们可以对比发现在使用APR连接器在处理高并发请求的时候是有一定的优势的能够提升web应用的处理请求能力。
4.2.2 Connector 其它属性调优
属性描述建议设置的值maxThreadstomcat能创建来处理请求的最大线程数默认值为200500minProcessors启动时创建的线程数最小线程数acceptCount指定当所有可以使用的处理请求的线程数都被使用时可以放到队列中的请求数超过这个数的请求将拒绝连接 默认值为100500compressibleMimeType该值用来指定哪些文件类型的文件可以进行压缩默认值为text/html,text/xml,text/plain,text/css,text/javascript,application/javascriptcompression开启gzip 压缩可以接受的值是 off(禁用压缩),on(开启压缩),force(强制压缩)1-9(等效于开启压缩并且设定压缩等级),开启了压缩也就意味着要占用更多的cpu资源onkeepAliveTimeout指connector两个HTTP请求直接的等待时间超过该时间没有接收到第二个HTTP请求就关闭连接默认是使用connectionTimeout 的值单位为毫秒30000processorCache进程缓冲器默认值是maxThreads的值,使用好该值可以提升并发请求。500
以上设置只是参考建议根据自己的业务进行设置并测试。 有很多参数tomcat 默认就给我设置好了比如URIEncoding,connectionTimeout,这些值都有默认值的。
4.2.3 Host 属性调优
属性描述建议配置startStopThreads指Host用于启动Context的线程数默认值为1如果多核建议配置为核心数-12unpackWARs默认为true,如果设置为true 表示将web应用程序war包解压false表示直接从war文件运行。设置为false对性能有一定的影响true
如果想并行启动多个web应用程序我们可以Host 的属性 startStopThreads 值设置大于1 但这也取决于我们的服务器是不是多核的。如果是多核的建议调大 startStopThreads 的值但不超过内核数。
4.2.4 tomcat线程关闭不掉调优(代码层)
如果我们使用的是自动发布的形式也就是替换war包的形式在tomcat安装文章中介绍了与jenkins 集成实现的那么容易出现的一个问题就是 上一次的线程没有关闭掉就启动了新的版本那么上一个版本的线程还存在也还在占用着资源这个问题的原因有可能是代码的问题我们可以尝试直接使用 catalina.sh 脚本stop 你会发现stop 掉后该tomcat 的线程还是存在的那么出现这种情况很大一部分原因就是 在java代码中有非守护线程也就是java代码未将线程设置为守护线程导致了tomcat 进行stop 不掉该线程的原因。那么这种情况有可能会导致两个web应用(新老版本)都在使用那这这个应用的定时任务可能就会执行两次就容易导致生产事故。
这种问题一方面会占用服务器资源。另外一方面还会容易导致生产事故我们可以用jstack 分析下未停止的线程并和开发区解决这个线程关闭不掉的问题。
4.2.5 AJP 连接器禁用
AJP协议在tomcat中的作用就是将该服务与其它HTTP服务器集成一般项目中没有用到该连接器所以可以禁用该连接器。
4.3 JVM 设置
在前面启动内存不足就谈到了
JAVA_OPTS-server -Xms1024m -Xmx1024m
其他的调优选项如果有多个connector 的话那么还可以通过 Executor 的属性进行调优。
