Tomcat性能调优参数简介

    近期，我们的一个项目进入了试运营的阶段，在系统部署至阿里云之后，我们发现整个系统跑起来还是比较慢的，而且，由于代码的各种不规范，以及一期进度十分赶的原因，缺少文档和完整的测试，整个的上线过程一波三折。好了，不多说，切入正题，项目使用的是学校提供的阿里云，基于windows server，web容器tomcat8.0（开发的java版本是7，所以tomcat9.0不支持），通过网络上和书籍上查找的相关资料，我们对tomcat的配置做了一些改变。

   首先介绍一下服务详细的环境信息：

       （1）Windows Server 2008 R2 Enterprise 64位

       （2）4GB 内存（操作系统占用2.3G内存）

       （3）jdk 1.7 64位

       （4）Tomcat 8.0解压缩版

   由于是在windows server下，因此我们改动的配置需要加在tomcat的bin目录下的catalina.bat中。如果是linux系统下，则需修改catalina.sh文件。Tomcat的优化分为两块：

       （1）Tomcat启动命令行中的优化。（Tomcat启动jvm时对jvm的参数配置优化）

       （2）Tomcat容器自身参数的优化。

   我们这里主要针对的是Tomcat启动命令的优化参数：

   set JAVA_OPTS=                -server                                               -Xms1000M                                                           -Xmx1000M

                                          -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

                                          -XX:+HeapDumpOnOutOfMemoryError   -XX:HeapDumpPath=C:\apache-tomcat-7.0.42\webapps

   不慌，我们来看一下每一个参数都代表什么意思，并且大致说明一下为什么要配置这个参数。

 

       （1）-server ： 一般开发工具中使用的是client，针对不同的服务器使用的不同，jvm server比jvm client 更优化，jvm server 启动较慢但启动后运行速度较快。jvm client  启动较快。jvm client 中能运行的可能在jvm server中运行出错 ，所以这样的话最好在开发、测试阶段都使用jvm server ，保持和服务器相同。不过一直用client，也没出现过什么问题，服务器端用的是server的。可能这种高技术含量的bug相当不容易出现了。JVM Server模式与client模式启动，最主要的差别在于：-Server模式启动时，速度较慢，但是一旦运行起来后，性能将会有很大的提升。JVM如果不显式指定是-Server模式还是-client模式。我们可以在命令行输入java -help查看到-server这个命令。

 

       （2）-Xms1000M和-Xmx1000M：这两个参数分别代表的是初始堆大小和最大堆大小。可以看到这两个值设置的是相等的，是因为如果一个系统随着并发数越来越高，它的内存使用情况逐步上升，直到达到最大内存大小，jvm就会进行垃圾回收，垃圾回收之后jvm就会重新分配内存，如果垃圾回收十分频繁，那jvm就要不断的去重新分配内存，这样就会浪费性能，因此一开始我们就把这两个设成一样，使得Tomcat在启动时就为最大化参数充分利用系统的效率，这个道理和jdbcconnection pool里的minpool size与maxpool size的需要设成一个数量是一样的原理。

 

       （3）-Xss512k ：设置每个线程的堆栈大小。JDK5.0以后每个线程堆栈大小为1M，以前每个线程堆栈大小为256K。更具应用的线程所需内存大小进行调整。在相同物理内存下，减小这个值能生成更多的线程。但是操作系统对一个进程内的线程数还是有限制的，不能无限生成，经验值在3000~5000左右。这个选项对性能影响比较大，需要严格的测试。我们这里为了保险起见用了512k。

 

        (4) -XX:+AggressiveOpts :这个参数的意思是启用这个参数，则每当JDK版本升级时，你的JVM都会使用最新加入的优化技术。

 

      （5）-XX:+UseBiasedLocking：启用一个优化了的线程锁（偏向锁），我们知道在tomcat中维护了一个线程池，每个http请求就是一个线程，线程多的时候就会有竞争的情况出现。这时候我们就需要锁来控制多线程访问竞争的资源，而这里说的偏向锁是JDK 1.6提出的一种锁优化方式，起核心思想是如果程序没有竞争，则取消之前已经取得锁的线程的同步操作。也就是说，某一个锁被一个线程获取之后，便进入了偏向锁模式，当该线程再次请求这个锁时，就无需再进行相关的同步操作，从而节省了操作时间。但是如果在此期间，有其他线程申请了这个锁，则退出偏向锁模式。关于偏向锁的原理，近期我会再发一篇博客好好的总结一下。

 

     （6）-XX:PermSize=128M和-XX:MaxPermSize=256M：表示设置初始持久代大小和最大永久代大小。事实上如果我们使用的是java8，那我们就需要配置的是元空间的参数：MetaspaceSize和MaxMetaspaceSize这两个参数。

 

     （7）-XX:+DisableExplicitGC：关闭代码中的System.gc()。

 

     （8）-XX:MaxTenuringThreshold=31：设置垃圾最大年龄（此参数只有在Serial 串行GC时有效）。我们知道新生代存在的唯一理由是优化垃圾回收(GC)的性能。更具体说，把堆划分为新生代和老年代有2个好处：简化了新对象的分配(只在新生代分配内存),可以更有效的清除不再需要的对象(即死对象)(新生代和老年代使用不同的GC算法)。设置这个值的大小需要我们根据本地的调试监控来得到一个理想的值，不能随意的设置，我们需要观察一下情况：如果从年龄分布中发现，有很多对象的年龄持续增长（增长到导致To区的使用率很高甚至爆满），在到达老年代阀值之前。这表示 -XX:MaxTenuringThreshold 设置过大。也就是说， 如果 -XX:MaxTenuringThreshold 的值大于1，但是很多对象年龄从未大于1.应该看下幸存区的目标使用率。如果幸存区使用率从未到达，这表示对象都被GC回收，这正是我们想要的。 如果幸存区使用率经常达到，有些年龄超过1的对象被移动到老年代中。这种情况，可以尝试调整幸存区大小或增加MaxTenuringThreshold值的大小。

 

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

 

    （10）-XX:+UseParNewGC：ParNew收集器是许多运行在Server模式下的虚拟机中首选的新生代收集器。ParNew收集器其实就是Serial收集器的多线程版本，除了Serial收集器外，目前只有它能与CMS收集器配合工作。

 

    （11）-XX:+CMSParallelRemarkEnabled：降低cms垃圾收集在初始标记和重新标记阶段（这两个阶段需要stop the world）的停顿。

 

    （12）-XX:+UseCMSCompactAtFullCollection：设置CMS 收集器在完成垃圾收集后是否要进行一次内存碎片整理。减少内存碎片。

 

    （13）-XX:LargePageSizeInBytes=128m：使用大的内存分页。CPU 是通过寻址来访问内存的。32 位 CPU 的寻址宽度是 0~0xFFFFFFFF ，计算后得到的大小是 4G，也就是说可支持的物理内存最大是 4G。但在实践过程中，碰到了这样的问题，程序需要使用 4G 内存，而可用物理内存小于 4G，导致程序不得不降低内存占用。为了解决此类问题，现代 CPU 引入了 MMU（Memory Management Unit 内存管理单元）。MMU 的核心思想是利用虚拟地址替代物理地址，即 CPU 寻址时使用虚址，由 MMU 负责将虚址映射为物理地址。MMU 的引入，解决了对物理内存的限制，对程序来说，就像自己在使用 4G 内存一样。内存分页 (Paging) 是在使用 MMU 的基础上，提出的一种内存管理机制。它将虚拟地址和物理地址按固定大小（4K）分割成页 (page) 和页帧 (page frame)，并保证页与页帧的大小相同。这种机制，从数据结构上，保证了访问内存的高效，并使 OS 能支持非连续性的内存分配。在程序内存不够用时，还可以将不常用的物理内存页转移到其他存储设备上，比如磁盘，这就是大家耳熟能详的虚拟内存。使用大的内存分页可以增强 CPU 的内存寻址能力，从而提升系统的性能。

 

   （14）-XX:+UseFastAccessorMethods ：原始类型的快速优化。

 

   （15）-XX:+UseCMSInitiatingOccupancyOnly：指示只有在老年代在使用了初始化的比例后，cms启动垃圾收集。

   （16）-Djava.awt.headless=true：在Java服务器程序需要进行部分图像处理功能时，建议将程序运行模式设置为headless，这样有助于服务器端有效控制程序运行状态和内存使用（可防止在处理大图片时发生内存溢出）。

 

   （17） -XX:+HeapDumpOnOutOfMemoryError   -XX:HeapDumpPath=C:\apache-tomcat-7.0.42\webapps：配置了发生oom的时候dump线程至指定目录。

   

 注：以上部分内容来自于网络

 参考链接：http://www.cnblogs.com/redcreen/archive/2011/05/04/2037057.html#CMSInitiatingOccupancyFraction_value

               http://ifeve.com/useful-jvm-flags-part-5-young-generation-garbage-collection/

               https://segmentfault.com/a/1190000005174819