Tomcat性能调优

最新推荐文章于 2023-05-13 23:18:26 发布

T748588330

最新推荐文章于 2023-05-13 23:18:26 发布

阅读量215

点赞数

分类专栏： tomcat 与 appache

tomcat 与 appache 专栏收录该内容

12 篇文章 0 订阅

订阅专栏

一、概述

Tomcat 的缺省配置是不能稳定长期运行的，也就是不适合生产环境，它会死机，让你不断重新启动，甚至在午夜时分唤醒你。

Tomcat 的优化不像其它软件那样，简简单单的修改几个参数就可以了，它的优化主要有三方面，分为系统优化，Tomcat 自身容器的优化，Java 虚拟机（JVM）调优。系统优化就不在介绍了，接下来就详细的介绍一下 Tomcat 本身与 JVM 优化，以 Tomcat 8 为例。

二、环境

OS: Cent OS 7
JDK: 1.8
Tomcat：apache-tomcat-8.5.8
三、Tomcat性能调优

1.启动参数优化

创建配置文件

touch setenv.sh
chmod 755 bin/setenv.sh
bin目录下新建的可执行文件setenv.sh会由tomcat自动调用，或添加到startup.sh中也可以。

JAVA_OPTS=”
-server -XX:PermSize=256M -XX:MaxPermSize=512M
-Xms2048M -Xmx2048M -Xmn768m -Xss512k -verbose:gc
-XX:+AggressiveOpts -XX:+UseBiasedLocking
-XX:+DisableExplicitGC -XX:MaxTenuringThreshold=31
-XX:+UseConcMarkSweepGC -XX:+UseParNewGC
-XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection
-XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods
-XX:+UseCMSInitiatingOccupancyOnly
-Djava.awt.headless=true
-Dfile.encoding=UTF-8”

参数详解

-server

我不管你什么理由，只要你的tomcat是运行在生产环境中的，这个参数必须给我加上
因为tomcat默认是以一种叫java –client的模式来运行的，server即意味着你的tomcat是以真实的production的模式在运行的，这也就意味着你的tomcat以server模式运行时将拥有：更大、更高的并发处理能力，更快更强捷的JVM垃圾回收机制，可以获得更多的负载与吞吐量。

注：-server一定要加。

-verbose:gc

表示输出虚拟机中GC的详细情况.

使用后输出如下:

[Full GC 168K->97K(1984K)， 0.0253873 secs]

解读如下:箭头前后的数据168K和97K分别表示垃圾收集GC前后所有存活对象使用的内存容量，说明有168K-97K=71K的对象容量被回收，括号内的数据1984K为堆内存的总容量，收集所需要的时间是0.0253873秒（这个时间在每次执行的时候会有所不同）

-Xms –Xmx

即JVM内存设置了，把Xms与Xmx两个值设成一样是最优的做法。

-Xms为初始堆大小,-Xmx 为最大堆大小

大家想一下这样的场景：

一个系统随着并发数越来越高，它的内存使用情况逐步上升，上升到最高点不能上升了，开始回落，你们不要认为这个回落就是好事情，由其是大起大落，在内存回落时它付出的代价是CPU高速开始运转进行垃圾回收，此时严重的甚至会造成你的系统出现“卡壳”就是你在好好的操作，突然网页像死在那边一样几秒甚至十几秒时间，因为JVM正在进行垃圾回收。

因此一开始我们就把这两个设成一样，使得Tomcat在启动时就为最大化参数充分利用系统的效率，这个道理和jdbcconnection pool里的minpool size与maxpool size的需要设成一个数量是一样的原理。

如何知道我的JVM能够使用最大值啊？拍脑袋？不行！在设这个最大内存即Xmx值时请先打开一个命令行，键入如下的命令：如果能正常输出版本信息，则表示JVM能使用的最大值，如果报错则表示不能使用

java -Xmx2048m -version
因此在设这个-Xms与-Xmx值时一定一定记得先这样测试一下，要不然直接加在tomcat启动命令行中你的tomcat就再也起不来了

–Xmn

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

-Xss

是指设定每个线程的堆栈大小。这个就要依据你的程序，看一个线程大约需要占用多少内存，可能会有多少线程同时运行等。一般设置成512k~1M就可以，最大不宜超过1M，要不然容易出现out ofmemory。

-XX:+AggressiveOpts

作用如其名（aggressive），启用这个参数，则每当JDK版本升级时，你的JVM都会使用最新加入的优化技术（如果有的话）

-XX:+UseBiasedLocking

启用一个优化了的线程锁，我们知道在我们的appserver，每个http请求就是一个线程，有的请求短有的请求长，就会有请求排队的现象，甚至还会出现线程阻塞，这个优化了的线程锁使得你的appserver内对线程处理自动进行最优调配。

-XX:PermSize=128M -XX:MaxPermSize=256M

JVM使用-XX:PermSize设置非堆内存初始值，默认是物理内存的1/64；在数据量的很大的文件导出时，一定要把这两个值设置上，否则会出现内存溢出的错误。由XX:MaxPermSize设置最大非堆内存的大小，默认是物理内存的1/4。那么，如果是物理内存4GB，那么64分之一就是64MB，这就是PermSize默认值，也就是永生代内存初始大小；四分之一是1024MB，这就是MaxPermSize默认大小。

-XX:+DisableExplicitGC

在程序代码中不允许有显示的调用System.gc()。

-XX:+UseParNewGC

对年轻代采用多线程并行回收，这样收得快。

-XX:+UseConcMarkSweepGC

即CMS gc，这一特性只有jdk1.5即后续版本才具有的功能，它使用的是gc估算触发和heap占用触发。我们知道频频繁的GC会造面JVM的大起大落从而影响到系统的效率，因此使用了CMS GC后可以在GC次数增多的情况下，每次GC的响应时间却很短，比如说使用了CMS GC后经过jprofiler的观察，GC被触发次数非常多，而每次GC耗时仅为几毫秒。

-XX:MaxTenuringThreshold=31

设置垃圾最大年龄。如果设置为0的话，则年轻代对象不经过Survivor区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在Survivor区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概率。这个值的设置是根据本地的jprofiler监控后得到的一个理想的值，不能一概而论原搬照抄。

-XX:+CMSParallelRemarkEnabled

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

-XX:+UseCMSCompactAtFullCollection

在使用concurrent gc 的情况下, 防止 memoryfragmention, 对live object 进行整理, 使 memory 碎片减少。

-XX:LargePageSizeInBytes

指定 Java heap的分页页面大小

-XX:+UseFastAccessorMethods

get,set 方法转成本地代码

-XX:+UseCMSInitiatingOccupancyOnly

指示只有在 oldgeneration 在使用了初始化的比例后concurrent collector 启动收集

-XX:CMSInitiatingOccupancyFraction=70

CMSInitiatingOccupancyFraction，这个参数设置有很大技巧，基本上满足(Xmx-Xmn)*(100- CMSInitiatingOccupancyFraction)/100>=Xmn就不会出现promotion failed。在我的应用中Xmx是6000，Xmn是512，那么Xmx-Xmn是5488M，也就是年老代有5488M，CMSInitiatingOccupancyFraction=90说明年老代到90%满的时候开始执行对年老代的并发垃圾回收（CMS），这时还剩10%的空间是5488*10%=548M，所以即使Xmn（也就是年轻代共512M）里所有对象都搬到年老代里，548M的空间也足够了，所以只要满足上面的公式，就不会出现垃圾回收时的promotion failed；因此这个参数的设置必须与Xmn关联在一起。

-Djava.awt.headless=true

这个参数一般我们都是放在最后使用的，这全参数的作用是这样的，有时我们会在我们的J2EE工程中使用一些图表工具如：jfreechart，用于在web网页输出GIF/JPG等流，在winodws环境下，一般我们的app server在输出图形时不会碰到什么问题，但是在linux/unix环境下经常会碰到一个exception导致你在winodws开发环境下图片显示的好好可是在linux/unix下却显示不出来，因此加上这个参数以免避这样的情况出现。上述这样的配置，基本上可以达到：

系统响应时间增快
JVM回收速度增快同时又不影响系统的响应率
JVM内存最大化利用
线程阻塞情况最小化
2.容器内的优化

前面主要对JVM的启动参数进行优化，接下来我们主要对Tomcat的容器进行优化，Tomcat容器的优化主要针对进行优化，包括

server.xml 配置说明

添加JMX监控

CATALINA_OPTS=”
-Dcom.sun.management.jmxremote.port=7091
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Djava.rmi.server.hostname=192.168.10.100”
添加JMX监控之后使用$JAVA_HOME/bin下的jconsole.exe或jvisualvm.exe查看。

jconsole使用方法：

jconsole输入如下地址：service:jmx:rmi:///jndi/rmi://172.16.100.114:8060/jmxrmi

jvisualvm使用方法：

jvisualvm操作步骤：文件->添加远程主机->输入主机名(IP)->确定->鼠标右键主机名->添加JMX连接->输入IP:PORT和安全凭证->确定

上面的jmxremote.authenticate在正式环境中请务必设为true并设置用户名/密码，减少安全隐患，或者注释掉CATALINA_OPTS(有时候出于性能调优的目的，才需要设置JMX)。

添加用户名/密码方法：

将$JAVA_HOME/jre/lib/management下的jmxremote.access和jmxremote.password.template复制到tomcat/conf中
将jmxremote.password.template重命名为jmxremote.password
修改jmxremote.password的权限chmod +w jmxremote.password
放开角色信息那俩行的注释(monitorRole QED,controlRole R&D),保存
再次修改jmxremote.password的权限chmod 0400 jmxremote.password
修改CATALINA_OPTS如下
Dcom.sun.management.jmxremote.authenticate=true
Dcom.sun.management.jmxremote.password.file=../conf/jmxremote.password
Dcom.sun.management.jmxremote.access.file=../conf/jmxremote.access