TOMCAT调优一（转）

时间 2019-11-30

标签 tomcat 栏目 Tomcat 繁體版

原文原文链接

从“第三天”的性能测试一节中，咱们得知了决定性能测试的几个重要指标，它们是：javascript

ü 吞吐量css

ü Responsetimehtml

ü Cpuloadjava

ü MemoryUsagelinux

咱们也在第三天的学习中对Apache作过了必定的优化，使其最优化上述4大核心指标的读数，那么咱们的Apache调优了，咱们的Tomcat也做些相应的调整，当完成今的课程后，到时你的“小猫”到时真的会“飞”起来的，因此请用心看完，这篇文章一方面用来向那位曾写过“Tomcat如何承受1000个用户”的做都的敬，一方面又是这篇原文的一个扩展，由于在把原文的知识用到相关的两个大工程中去后解决了：程序员

1) 承受更大并发用户数web

2) 取得了良好的性能与改善（系统平均性能提高达20倍，极端一个交易达80倍）。sql

另外值的一提的是，咱们当时工程里用的“小猫”是跑在32位机下的，也就是咱们的JVM最大受到2GB内存的限制，都已经跑成“飞”了。。。。。。若是在64位机下跑这头“小猫”。。。。。。你们可想而知，会获得什么样的效果呢？下面就请请详细的设置吧！数据库

2、一切基于JVM（内存）的优化

2.1 32位操做系统与64位操做系统中JVM的对比

咱们通常的开发人员，基本用的是都是32位的Windows系统，这就致使了一个严重的问题即：32位windows系统对内存限制，下面先来看一个比较的表格：apache

操做系统	操做系统位数	内存限制	解决办法
Winxp	32	4GB	超级兔子
Win7	32	4GB	能够经过设置/PAE
Win2003	32	能够突破4GB达16GB	必须要装win2003 advanced server且要打上sp2补丁
Win7	64	无限制	机器能插多少内存，系统内存就能支持到多大
Win2003	64	无限制	机器能插多少内存，系统内存就能支持到多大
Linux	64	无限制	机器能插多少内存，系统内存就能支持到多大
Unix	64	无限制	机器能插多少内存，系统内存就能支持到多大

上述问题解决后，咱们又碰到一个新的问题，32位系统下JVM对内存的限制：不能突破2GB内存，即便你在Win2003 Advanced Server下你的机器装有8GB-16GB的内存，而你的JAVA，只能用到2GB的内存。

其实我一直很想推荐你们使用Linux或者是Mac操做系统的，并且要装64位，由于必竟咱们是开发用的不是打游戏用的，而Java源自Unix归于Unix（Linux只是运行在PC上的Unix而己）。

因此不少开发人员运行在win32位系统上更有甚者在生产环境下都会布署win32位的系统，那么这时你的Tomcat要优化，就要讲究点技巧了。而在64位操做系统上不管是系统内存仍是JVM都没有受到2GB这样的限制。

Tomcat的优化分红两块：

ü Tomcat启动命令行中的优化参数即JVM优化

ü Tomcat容器自身参数的优化（这块很像ApacheHttp Server）

这一节先要讲的是Tomcat启动命令行中的优化参数。

Tomcat首先跑在JVM之上的，由于它的启动其实也只是一个java命令行，首先咱们须要对这个JAVA的启动命令行进行调优。

须要注意的是：

这边讨论的JVM优化是基于Oracle Sun的jdk1.6版有以上，其它JDK或者低版本JDK不适用。

2.2 Tomcat启动行参数的优化

Tomcat 的启动参数位于tomcat的安装目录\bin目录下，若是你是Linux操做系统就是catalina.sh文件，若是你是Windows操做系统那么你须要改动的就是catalina.bat文件。打开该文件，通常该文件头部是一堆的由##包裹着的注释文字，找到注释文字的最后一段如：

# $Id: catalina.sh 522797 2007-03-27 07:10:29Z fhanik $

# -----------------------------------------------------------------------------

# OS specific support. $var _must_ be set to either true or false.

敲入一个回车，加入以下的参数

Linux系统中tomcat的启动参数

export JAVA_OPTS="-server -Xms1400M -Xmx1400M -Xss512k -XX:+AggressiveOpts -XX:+UseBiasedLocking -XX:PermSize=128M -XX:MaxPermSize=256M -XX:+DisableExplicitGC -XX:MaxTenuringThreshold=31 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -Djava.awt.headless=true "

Windows系统中tomcat的启动参数

set JAVA_OPTS=-server -Xms1400M -Xmx1400M -Xss512k -XX:+AggressiveOpts -XX:+UseBiasedLocking -XX:PermSize=128M -XX:MaxPermSize=256M -XX:+DisableExplicitGC -XX:MaxTenuringThreshold=31 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:LargePageSizeInBytes=128m -XX:+UseFastAccessorMethods -XX:+UseCMSInitiatingOccupancyOnly -Djava.awt.headless=true

上面参数好多啊，可能有人写到如今都没见一个tomcat的启动命令里加了这么多参数，固然，这些参数只是我机器上的，不必定适合你，尤为是参数后的value（值）是须要根据你本身的实际状况来设置的。

参数解释：

ü -server

我无论你什么理由，只要你的tomcat是运行在生产环境中的，这个参数必须给我加上

由于tomcat默认是以一种叫java –client的模式来运行的，server即意味着你的tomcat是以真实的production的模式在运行的，这也就意味着你的tomcat以server模式运行时将拥有：更大、更高的并发处理能力，更快更强捷的JVM垃圾回收机制，能够得到更多的负载与吞吐量。。。更。。。还有更。。。

Y给我记住啊，要否则这个-server都不加，那是要打屁股了。

ü -Xms–Xmx

即JVM内存设置了，把Xms与Xmx两个值设成同样是最优的作法，有人说Xms为最小值，Xmx为最大值不是挺好的，这样设置还比较人性化，科学化。人性？科学？你个头啊。

你们想一下这样的场景：

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

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

如何知道个人JVM可以使用最大值啊？拍脑壳？不行！

在设这个最大内存即Xmx值时请先打开一个命令行，键入以下的命令：

看，可以正常显示JDK的版本信息，说明，这个值你可以用。不是说32位系统下最高可以使用2GB内存吗？即：2048m，咱们不防来试试

能够吗？不能够！不要说2048m呢，咱们小一点，试试1700m如何

嘿嘿，连1700m都不能够，更不要说2048m了呢，2048m只是一个理论数值，这样说吧我这边有几台机器，有的机器-Xmx1800都没问题，有的机器最高只能到-Xmx1500m。

所以在设这个-Xms与-Xmx值时必定必定记得先这样测试一下，要否则直接加在tomcat启动命令行中你的tomcat就再也起不来了，要飞是飞不了，直接成了一只瘟猫了。

ü –Xmn

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

ü -Xss

是指设定每一个线程的堆栈大小。这个就要依据你的程序，看一个线程大约须要占用多少内存，可能会有多少线程同时运行等。通常不易设置超过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()”。看到过有两个极品工程中每次在DAO操做结束时手动调用System.gc()一下，以为这样作好像可以解决它们的out ofmemory问题同样，付出的代价就是系统响应时间严重下降，就和我在关于Xms,Xmx里的解释的原理同样，这样去调用GC致使系统的JVM大起大落，性能不到什么地方去哟！

ü -XX:+UseParNewGC

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

ü -XX:+UseConcMarkSweepGC

即CMS gc，这一特性只有jdk1.5即后续版本才具备的功能，它使用的是gc估算触发和heap占用触发。

咱们知道频频繁的GC会造面JVM的大起大落从而影响到系统的效率，所以使用了CMS GC后能够在GC次数增多的状况下，每次GC的响应时间却很短，好比说使用了CMS GC后通过jprofiler的观察，GC被触发次数很是多，而每次GC耗时仅为几毫秒。

ü -XX:MaxTenuringThreshold

设置垃圾最大年龄。若是设置为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是5488兆，也就是年老代有5488 兆，CMSInitiatingOccupancyFraction=90说明年老代到90%满的时候开始执行对年老代的并发垃圾回收（CMS），这时还剩10%的空间是5488*10%=548兆，因此即便Xmn（也就是年轻代共512兆）里全部对象都搬到年老代里，548兆的空间也足够了，因此只要满足上面的公式，就不会出现垃圾回收时的promotion failed；

所以这个参数的设置必须与Xmn关联在一块儿。

ü -Djava.awt.headless=true

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

上述这样的配置，基本上能够达到：

ü 系统响应时间增快

ü JVM回收速度增快同时又不影响系统的响应率

ü JVM内存最大化利用

ü 线程阻塞状况最小化

2.3 Tomcat容器内的优化

前面咱们对Tomcat启动时的命令进行了优化，增长了系统的JVM可以使用数、垃圾回收效率与线程阻塞状况、增长了系统响应效率等还有一个很重要的指标，咱们没有去作优化，就是吞吐量。

还记得咱们在第三天的学习中说的，这个系统自己能够处理1000，你没有优化和配置致使它默认只能处理25。所以下面咱们来看Tomcat容器内的优化。

打开tomcat安装目录\conf\server.xml文件，定位到这一行：

<Connector port="8080" protocol="HTTP/1.1"

这一行就是咱们的tomcat容器性能参数设置的地方，它通常都会有一个默认值，这些默认值是远远不够咱们的使用的，咱们来看通过更改后的这一段的配置：

<Connector port="8080" protocol="HTTP/1.1"

URIEncoding="UTF-8" minSpareThreads="25" maxSpareThreads="75"

enableLookups="false" disableUploadTimeout="true" connectionTimeout="20000"

acceptCount="300" maxThreads="300" maxProcessors="1000" minProcessors="5"

useURIValidationHack="false"

compression="on" compressionMinSize="2048"

compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain"

redirectPort="8443"

好大一陀唉。。。。。。

不要紧，一个个来解释

ü URIEncoding=”UTF-8”

使得tomcat能够解析含有中文名的文件的url，真方便，不像apache里还有搞个mod_encoding，还要手工编译

ü maxSpareThreads

maxSpareThreads 的意思就是若是空闲状态的线程数多于设置的数目，则将这些线程停止，减小这个池中的线程总数。

ü minSpareThreads

最小备用线程数，tomcat启动时的初始化的线程数。

ü enableLookups

这个功效和Apache中的HostnameLookups同样，设为关闭。

ü connectionTimeout

connectionTimeout为网络链接超时时间毫秒数。

ü maxThreads

maxThreads Tomcat使用线程来处理接收的每一个请求。这个值表示Tomcat可建立的最大的线程数，即最大并发数。

ü acceptCount

acceptCount是当线程数达到maxThreads后，后续请求会被放入一个等待队列，这个acceptCount是这个队列的大小，若是这个队列也满了，就直接refuse connection

ü maxProcessors与minProcessors

在 Java中线程是程序运行时的路径，是在一个程序中与其它控制线程无关的、可以独立运行的代码段。它们共享相同的地址空间。多线程帮助程序员写出CPU最大利用率的高效程序，使空闲时间保持最低，从而接受更多的请求。

一般Windows是1000个左右，Linux是2000个左右。

ü useURIValidationHack

咱们来看一下tomcat中的一段源码：

security

if (connector.getUseURIValidationHack()) {

String uri = validate(request.getRequestURI());

if (uri == null) {

res.setStatus(400);

res.setMessage("Invalid URI");

throw new IOException("Invalid URI");

} else {

req.requestURI().setString(uri);

// Redoing the URI decoding

req.decodedURI().duplicate(req.requestURI());

req.getURLDecoder().convert(req.decodedURI(), true);

}

能够看到若是把useURIValidationHack设成"false"，能够减小它对一些url的没必要要的检查从而减省开销。

ü enableLookups="false"

为了消除DNS查询对性能的影响咱们能够关闭DNS查询，方式是修改server.xml文件中的enableLookups参数值。

ü disableUploadTimeout

相似于Apache中的keeyalive同样

ü 给Tomcat配置gzip压缩(HTTP压缩)功能

compression="on" compressionMinSize="2048"

compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain"

HTTP 压缩能够大大提升浏览网站的速度，它的原理是，在客户端请求网页后，从服务器端将网页文件压缩，再下载到客户端，由客户端的浏览器负责解压缩并浏览。相对于普通的浏览过程HTML,CSS,Javascript , Text ，它能够节省40%左右的流量。更为重要的是，它能够对动态生成的，包括CGI、PHP , JSP , ASP , Servlet,SHTML等输出的网页也能进行压缩，压缩效率惊人。

1)compression="on" 打开压缩功能

2)compressionMinSize="2048" 启用压缩的输出内容大小，这里面默认为2KB

3)noCompressionUserAgents="gozilla, traviata" 对于如下的浏览器，不启用压缩

4)compressableMimeType="text/html,text/xml"　压缩类型

最后不要忘了把8443端口的地方也加上一样的配置，由于若是咱们走https协议的话，咱们将会用到8443端口这个段的配置，对吧？

<Connector port="8443" protocol="HTTP/1.1"

URIEncoding="UTF-8" minSpareThreads="25" maxSpareThreads="75"

enableLookups="false" disableUploadTimeout="true" connectionTimeout="20000"

acceptCount="300" maxThreads="300" maxProcessors="1000" minProcessors="5"

useURIValidationHack="false"

compression="on" compressionMinSize="2048"

compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain"

SSLEnabled="true"

scheme="https" secure="true"

clientAuth="false" sslProtocol="TLS"

keystoreFile="d:/tomcat2/conf/shnlap93.jks" keystorePass="aaaaaa"

好了，全部的Tomcat优化的地方都加上了。结合第三天中的Apache的性能优化，咱们这个架构能够“飞奔”起来了，固然这边把有说起任何关于数据库优化的步骤，但仅凭这两步，咱们的系统已经有了很大的提高。

举个真实的例子：上一个项目，通过4轮performance testing，第一轮进行了问题的定位，第二轮就是进行了apache+tomcat/weblogic的优化，第三轮是作集群优化，第四轮是sql与codes的优化。

在到达第二轮时，咱们的性能已经提高了多少倍呢？咱们来看一个loaderrunner的截图吧：

左边第一列是第一轮没有通过任何调优的压力测试报告。

右边这一列是通过了apache优化，tomcat优化后获得的压力测试报告。

你们看看，这就提升了多少倍？这还只是在没有改动代码的状况下获得的改善，如今明白了好好的调优一

个apache和tomcat实际上是多么的重要了？若是加上后面的代码、SQL的调优、数据库的调优。。。。。。因此我在上一个工程中有单笔交易性能（不管是吞吐量、响应时间）提升了80倍这样的极端例子的存在。