【多处摘抄】Tomcat监视与调优

文章摘抄大量内容，已附上摘抄地址，未找到最初博文作者，在此对原作者表述感谢：   

         最近调整了公司的Web容器，然后把项目转移到了idea，并且重新分了包，我以前很多重复的东西整合了一下，但是最近线下经常服务自动停止。查看日志什么的没有异常信息，查看进程发现进程都已经停了。

环境：Ubuntu 14.04.3 LTS (GNU/Linux 3.19.0-25-generic x86_64、JDK8、Tomcat8

        于是有以下思路：

1、通过工具查看内存占用情况：

a、使用自带的工具查看:输入eg:localhost:8080,选择管理选项，能简单查看内存状态，但功能有限。

b、使用其它工具查看。

c、看毛线、往大了搞。

2、根据实际需求调整tomcat可用内存以及各项启动参数

摘抄：（各个参数的解释）：https://blog.csdn.net/liqi_q/article/details/53031868（非原作者）

修改：Linux操作系统是catalina.sh文件，如果你是Windows就是catalina.bat

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

 -server

因为tomcat默认是以一种叫java –client的模式来运行的

-Xms–Xmx

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

我们就把这两个设成一样，使得Tomcat在启动时就为最大化参数充分利用系统的效率，这个道理和jdbcconnection pool里的minpool size与maxpool size的需要设成一个数量是一样的原理。大起大落，在内存回落时它付出的代价是CPU高速开始运转进行垃圾回收，此时严重的甚至会造成你的系统出现“卡壳”

 –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内存最大化利用

   线程阻塞情况最小化

打开tomcat安装目录confserver.xml文件，定位到这某一行修改：

          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端口这个段的配置，对吧？

   

               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的优化。

摘抄：以下配置项摘抄地址:https://blog.csdn.net/jiang1245764446/article/details/51898723

设置 Tomcat 相关变量：

• sudo vim /usr/program/tomcat8/bin/catalina.sh
• 在配置文件的可编辑内容最上面（98 行开始），加上如下内容（具体参数根据你服务器情况自行修改）：

JAVA_HOME=/usr/program/jdk1.8.0_72
CATALINA_HOME=/usr/program/tomcat8
CATALINA_OPTS="-server -Xms528m -Xmx528m -XX:PermSize=256m -XX:MaxPermSize=358m"
CATALINA_PID=$CATALINA_HOME/catalina.pid

 

3、百度其它优化方式例如JVM调优

 

 

• 模型资料来源：http://xmuzyq.iteye.com/blog/599750
• Java 的内存模型分为：
  • Young，年轻代（易被 GC）。Young 区被划分为三部分，Eden 区和两个大小严格相同的 Survivor 区，其中 Survivor 区间中，某一时刻只有其中一个是被使用的，另外一个留做垃圾收集时复制对象用，在 Young 区间变满的时候，minor GC 就会将存活的对象移到空闲的Survivor 区间中，根据 JVM 的策略，在经过几次垃圾收集后，任然存活于 Survivor 的对象将被移动到 Tenured 区间。
  • Tenured，终身代。Tenured 区主要保存生命周期长的对象，一般是一些老的对象，当一些对象在 Young 复制转移一定的次数以后，对象就会被转移到 Tenured 区，一般如果系统中用了 application 级别的缓存，缓存中的对象往往会被转移到这一区间。
  • Perm，永久代。主要保存 class,method,filed 对象，这部门的空间一般不会溢出，除非一次性加载了很多的类，不过在涉及到热部署的应用服务器的时候，有时候会遇到 java.lang.OutOfMemoryError : PermGen space 的错误，造成这个错误的很大原因就有可能是每次都重新部署，但是重新部署后，类的 class 没有被卸载掉，这样就造成了大量的 class 对象保存在了 perm 中，这种情况下，一般重新启动应用服务器可以解决问题。
• Linux 修改 /usr/program/tomcat7/bin/catalina.sh 文件，把下面信息添加到文件第一行。Windows 和 Linux 有点不一样的地方在于，在 Linux 下，下面的的参数值是被引号包围的，而 Windows 不需要引号包围。
  • 如果服务器只运行一个 Tomcat
    • 机子内存如果是 8G，一般 PermSize 配置是主要保证系统能稳定起来就行：
      • JAVA_OPTS="-Dfile.encoding=UTF-8 -server -Xms6144m -Xmx6144m -XX:NewSize=1024m -XX:MaxNewSize=2048m -XX:PermSize=512m -XX:MaxPermSize=512m -XX:MaxTenuringThreshold=10 -XX:NewRatio=2 -XX:+DisableExplicitGC"
    • 机子内存如果是 16G，一般 PermSize 配置是主要保证系统能稳定起来就行：
      • JAVA_OPTS="-Dfile.encoding=UTF-8 -server -Xms13312m -Xmx13312m -XX:NewSize=3072m -XX:MaxNewSize=4096m -XX:PermSize=512m -XX:MaxPermSize=512m -XX:MaxTenuringThreshold=10 -XX:NewRatio=2 -XX:+DisableExplicitGC"
    • 机子内存如果是 32G，一般 PermSize 配置是主要保证系统能稳定起来就行：
      • JAVA_OPTS="-Dfile.encoding=UTF-8 -server -Xms29696m -Xmx29696m -XX:NewSize=6144m -XX:MaxNewSize=9216m -XX:PermSize=1024m -XX:MaxPermSize=1024m -XX:MaxTenuringThreshold=10 -XX:NewRatio=2 -XX:+DisableExplicitGC"
  • 如果是开发机
    • -Xms550m -Xmx1250m -XX:PermSize=550m -XX:MaxPermSize=1250m
  • 参数说明：

                        

-Dfile.encoding：默认文件编码
-server：表示这是应用于服务器的配置，JVM 内部会有特殊处理的
-Xmx1024m：设置JVM最大可用内存为1024MB
-Xms1024m：设置JVM最小内存为1024m。此值可以设置与-Xmx相同，以避免每次垃圾回收完成后JVM重新分配内存。
-XX:NewSize：设置年轻代大小
-XX:MaxNewSize：设置最大的年轻代大小
-XX:PermSize：设置永久代大小
-XX:MaxPermSize：设置最大永久代大小
-XX:NewRatio=4：设置年轻代（包括 Eden 和两个 Survivor 区）与终身代的比值（除去永久代）。设置为 4，则年轻代与终身代所占比值为 1：4，年轻代占整个堆栈的 1/5
-XX:MaxTenuringThreshold=10：设置垃圾最大年龄，默认为：15。如果设置为 0 的话，则年轻代对象不经过 Survivor 区，直接进入年老代。对于年老代比较多的应用，可以提高效率。如果将此值设置为一个较大值，则年轻代对象会在 Survivor 区进行多次复制，这样可以增加对象再年轻代的存活时间，增加在年轻代即被回收的概论。
-XX:+DisableExplicitGC：这个将会忽略手动调用 GC 的代码使得 System.gc() 的调用就会变成一个空调用，完全不会触发任何 GC

实际使用总结：

grep MemTotal /proc/meminfo 命令看下内存大小

根据内存总大小配置 tomcat/bin/catalina.sh ,最上面（第二行）插入：

JAVA_OPTS="-Dfile.encoding=UTF-8 -server -Xms6144m -Xmx6144m -XX:NewSize=1024m -XX:MaxNewSize=2048m -XX:PermSize=512m -XX:MaxPermSize=512m -XX:MaxTenuringThreshold=10 -XX:NewRatio=2 -XX:+DisableExplicitGC"
CATALINA_OPTS="-server -Xms1024m -Xmx1024m -XX:PermSize=256m -XX:MaxPermSize=358m"

：wq保存退出

catalina.sh文件

运行成功，感觉速度快了好多，然后需要进行监控验证一下：

监控：

20180409，早上来测试机又挂了

https://my.oschina.net/kone/blog/157239 配置好了无法连接，本地倒是可以看。。。

下面这个博客是可以用的：通过java自带的visualVM远程监控：

http://ihuangweiwei.iteye.com/blog/1219302

修改Catalina中的配置以及配置host文件，或使用他文中的指定ip：

新增javaopt

#!/bin/sh
#JAVA_OPTS='-server -Xmsm -Xmx2048m XX:PermSize=256M -XX:MaxPermSize=512M'

JAVA_OPTS="-Dfile.encoding=UTF-8 -server -Xms6144m -Xmx6144m -XX:NewSize=1024m -XX:MaxNewSize=2048m -XX:PermSize=512m -XX:MaxPermSize=512m -XX:MaxTenuringThreshold=10 -XX:NewRatio=2 -XX:+DisableExplicitGC -Dcom.sun.management.jmxremote.port=8999 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false"

如果未配置host应加上：（-Djava.rmi.server.hostname=192.168.1.54）

CATALINA_OPTS="-server -Xms1024m -Xmx1024m -XX:PermSize=256m -XX:MaxPermSize=358m"

保存并建立JMX链接：

监视了几分钟，发现了不正常的地方：

测试机并未有人测试，然而堆内存的使用却一直往上走。。。9:05我登录了一下，内存使用如下：

有人使用的时候，gc回收开始工作，所以我猜测是不是没人使用时无法触发gc导致最终内存溢出？：

停止对线下测试机使用：

一天下来未发生异常状况，继续监测。。。

20180410线下正常未挂，继续监测

20180410下午挂了，挂的时候内存以及日志如下：

可以看到好像跟内存关系不大？

再看日志：

连接池对象回收失败，内存溢出，从根本上解决问题的话就是监控连接池使用情况，此时先加大内存观察下：

给多少内存吃多少内存？

下面开始处理连接池：

搜索：the JDBC driver [com.mysql.jdbc.Driver] but failed to unregister it when the web application was sto

答案：

Your application doesn't have a flaw. It is the design of JDBC. The JDBC driver gets loaded and registered by the webapp when it creates a database connection for the first time.

That means that the driver is loaded with the web application class loader. On undeployment the driver doesn't get deregistered which in turn prevents your webapp classes from GC. That creates effectively a memory leak.

To prevent this particular memory leak you should edit your tomcat/conf/server.xml and change

<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />

to

<Listener 
className="org.apache.catalina.core.JreMemoryLeakPreventionListener"
classesToInitialize="com.mysql.jdbc.NonRegisteringDriver" />

Exclude the JDBC driver from your webapp artifact and put it into the tomcat/lib directory.Now the JDBC driver gets loaded by Tomcat on startup and isn't linked to any webapps class loader.

Why should I modify the server.xml?

Another memory leaks manifests due to MySQL's 'Abandoned connection cleanup thread'. This thread starts with the first request and holds a reference to the webapp's classloader. With classesToInitialize you can prevent this memory leak too.

shareimprove this answer

edited Jan 25 '16 at 18:48

 

总结：问题的原因与如日志所报，与连接池有关，排错过程思路总结：

1、查看日志》能定位就定位

2、查看资源占用情况，加大容器资源，排除资源问题

3、更换数据源连接池或版本或配置参数，以排除连接池问题（问题所在，定位到则查找可行方案，连接池参数优化，更换等）

4、继续跟踪，查看后续是否再次出现其他问题（跟踪中发现tail日志时直接退出会导致服务器停止）

5、开发中注意节省重量级资源，如连接池资源非常重！重的吓人！还有流的关闭，StringBuffer，变量的声明，虽然

现在硬件条件都比较好，但是积少成多。