tomcat调优配置

今天遇到一个tomcat服务注册后配置Java参数没效果&＃xff0c;最后在注册表中删除原来的tomcat服务后&＃xff0c;顺便看了一下tomcat的调优配置&＃xff0c;看别人总结的不错&＃xff0c;就转载一下。

Tomcat、Jetty、GlassFish 等等这系列 Web容器/应用服务器&＃xff0c;虽然做为容器&＃xff0c;提供的是一个 Java Web 的运行时环境&＃xff0c;以支持Servlet/JSP 等等这些内容的运行&＃xff0c;但我们都很清楚&＃xff0c;其本质上还是一个 Java 应用程序。 每次对于 容器的启动运行&＃xff0c;都是把这个 Java 程序跑起来&＃xff0c;来实现 Web 容器的能力。

 

做为一类“特殊”的 Java 应用程序&＃xff0c;和任务其他的 Java 应用一样&＃xff0c;需要使用到JVM&＃xff0c;会有堆&＃xff0c;会使用到垃圾回收&＃xff0c;会涉及到不同的堆分区比例...  

因此在对Web 容器( 应用服务器) 的调优中必不可少的是对于 JVM 的调优。

 

 

对于 JVM 的调优&＃xff0c;主要有两个方面考虑&＃xff1a;

 

内存大小配置

垃圾回收算法选择

 

当然&＃xff0c;确切的说&＃xff0c;以上两点并不互相独立&＃xff0c;内存的大小配置也会影响垃圾回收的执行效率。

 

其中内存大小配置&＃xff0c;最主要做的有

 

确定内存占用的总大小

确定内存中各个代(Gen) 的大小划分

 

 

内存大小配置

 

所谓内存大小的占用&＃xff0c;是指应用程序启动后稳定运行一小段时间时&＃xff0c;观察到的内存占用情况。

以 HotSpot 虚拟机为例&＃xff0c;Java 堆主要有三个空间&＃xff1a;

新生代、老年代和永久代。 

 

根据不同应用的特别&＃xff0c;观察应用对于内存的占用&＃xff0c;如果有大量的临时对象&＃xff0c;不会重复使用&＃xff0c;则可以调整 New Gen&＃xff0c; 这样这些临时对象就在新生代创建完成&＃xff0c;并在 Minor GC 产生时被回收&＃xff0c;这样较短生存活的对象不会晋升到老年代&＃xff0c;从而可以避免垃圾堆集产生 Full GC。 

 

理想状态下&＃xff0c;短期存活的对象都只在新生代完成生命周期&＃xff0c;被费时劲少的 

Minor GC 回收完成&＃xff0c; 而长期存活&＃xff0c;将会多次使用的在多次回收之后晋升到老年代&＃xff0c; 最终经过 Full GC 完成生命周期。

 

这里涉及到关于内存大小的调整参数有&＃xff1a;

 

-Xms

-Xmx

 

这两个参数用于配置 heap 的起始大小和最大值。这里需要经过观察&＃xff0c;找一个合适的值&＃xff0c;设置太大会导致内存浪费&＃xff0c;同时也会导致垃圾回收耗时太长。对于 Tomcat 来说&＃xff0c;一般都会将初始值和最大值设置为相同值&＃xff0c;这样就避免在初始内存不足时触发 Full GC 来进行扩展内存。

 

设定 heap 大小之后&＃xff0c;要根据对象生命周期的特征&＃xff0c;来调整新生代与老年代的大小比例。

 

涉及到的参数有&＃xff1a;

-XX:NewSize

-XX:NewRatio

-XX:MaxNewSize

-Xmn

 

第一个是直接设置新生代初始大小&＃xff0c;第二个是设置比例(Ratio)。太高或太低都会导致 GC 不能高效的工作。毕竟 Minor GC 也是要耗时的。最后一个设置新生代的初始值和最大值相同&＃xff0c;堆空间的变化不影响其值。

 

对于使用了大量第三方类库的应用来说&＃xff0c;会加载许多框架依赖的类&＃xff0c;使用过程中可能会遇到因为Perm Gen 不足产生的 OOM&＃xff0c;这种情况可以通过观察稳定状态下 Perm 区的占用&＃xff0c;再通过参数设置。

 

-XX:PermSize

-XX:MaxPermSize

-XX:MaxMetaspaceSize

 

第一个会设置Perm区的初始大小&＃xff0c;第二个用于设置Perm 区的最大值。在Java 8的时候&＃xff0c; Perm 区被移除&＃xff0c;改为Metaspace&＃xff0c;不过如果遇到类似的OOM,依然可以调整其大小。

 

此外&＃xff0c;对于使用大量线程的应用&＃xff0c;也可以配置 -Xss&＃xff0c;主要用于设置单个线程的stack 大小。注意&＃xff0c;是单个的大小&＃xff0c;因此设置值越大&＃xff0c;会占用越大&＃xff0c;可用的线程数也就越少。

 

这里的配置一般对于-X开始的可以直接在后面用数字加单位&＃xff0c;而-XX的则需要等号后数字再加单位&＃xff0c;例如&＃xff1a;

java -Xms100m -Xmx200m -XX:PermSize&＃61;300m

 

这里数字后的单可以是m,g,k代表计算机中的不同单位。

 

那我们前面一直在说根据不同的应用&＃xff0c;观察分析设置堆的大小&＃xff0c;堆的各个代的大小&＃xff0c;那具体观察什么呢&＃xff1f;

 

我们一般在JVM的配置中增加一些打印 GC 日志的选项&＃xff0c;配置方式和上面的类似&＃xff0c;这样在 GC 产生时&＃xff0c;会打印出各个代占用的大小&＃xff0c;具体触发时间等。推荐的配置有以下几个&＃xff1a;

 

-XX:&＃43;PrintGCTimeStamps

-XX:&＃43;PrintGCDetails

-Xloggc:<文件名>

-XX:PrintGCDateStamps

 

第一个和第四个选项可以任选一个&＃xff0c;第一个打印自JVM启动以来的时间&＃xff0c;一般也称为uptime, 第四个打印的是系统当前日期和时间。

 

根据 GC 日志产生的内容&＃xff0c;来观察具体的大小&＃xff0c;开始使用上述的配置参数进行调整。当然&＃xff0c;也可以用 JConsole, JVisual VM 这些工具可视化的进行了解再调整。工具的使用可以参考历史文章

Java七武器系列多情环 --多功能Profiling工具 JVisual VM

 

 

垃圾回收算法

 

不同的垃圾回收算法&＃xff0c;对于应用的影响很大。一方面可能在一个服务器上却使用了单线程的回收算法&＃xff0c;也可能应用对于响应要求很高&＃xff0c;但却使用了一个吞吐量优先的算法&＃xff0c;导致响应太慢。

所以对于垃圾回收算法的选择&＃xff0c;一般都是根据应用的特点&＃xff0c;是要低延迟还是高吞吐量&＃xff0c;选择合适的算法。我们前面也提到&＃xff0c;垃圾回收算法和内存的大小配置并非独立的&＃xff0c;内存设置大是回收的频率会降低&＃xff0c;但每次的执行时间也会变长。所以这里也是一个需要权衡的地方。

 

延迟、吞吐量调优

其他 JVM 配置

 

垃圾回收算法对应到的就是不同的垃圾收集器&＃xff0c;具体到在 JVM 中的配置&＃xff0c;是使用 -XX:&＃43;UseParallelOldGC 或者 -XX:&＃43;UseConcMarkSweepGC 这种不同的收集器来达到选择算法的目的。

 

其中 ParallelGC 也称为 吞吐量优先收集器&＃xff0c;可以提升应用的吞吐量&＃xff0c;但在老年代大小调整之&＃xff0c;进行几次垃圾回收后&＃xff0c;不能满足应用的低延迟要求。

一般常用到ConcMarkSweepGC&＃xff0c; 也称之为 CMS GC&＃xff0c;其可以做到老年代的垃圾回收与应用程序的纯种并行执行&＃xff0c;所以可以实现低延迟。

 

这里注意&＃xff0c;由于 CMS GC 和其他GC回收算法使用的框架不同&＃xff0c;因此不能混用&＃xff0c;在使用CMS 进行老年代回收时&＃xff0c;新生代默认使用了单线程回收算法&＃xff0c;此时可以通过配置 -XX:&＃43;UseParNewGC来使用 新生代并行回收。

 

由于CMS是垃圾回收和应用线程并行&＃xff0c;因此需要额外的CPU处理资源&＃xff0c;如果只有一个CPU的机器&＃xff0c;或者有多个忙碌的CPU&＃xff0c;又想要使用低延迟的收集器&＃xff0c;此时可以通过配置 CMS 收集器的增量模式来进行回收&＃xff0c;通过指定 -XX:&＃43;CMSIncrementalMode 来开启增量模式。此时交替运行垃圾收集器应用线程。通过配置 

-XX:CMSIncrementalSafetyFactor&＃61;X&＃xff0c; -XX:CMSIncrementalDutyCycleMin&＃61;Y,

-XX:CMSIncrementalPacing 可以控制垃圾收集后台线程为应用线程让出多少CPU周期。

 

参数-XX:&＃43;CMSParallelRemarkEnabled 用来降低标记停顿&＃xff0c;另外由于CMS 回收后的老年代内存空间并不是连续的&＃xff0c;因此通过参数

-XX:&＃43;UseCMSCompactAtFullCollection 在Full GC的时候对年老代的压缩。

 

在JDK1.7 的时候引入了 G1 收集器&＃xff0c;可以通过配置-XX:&＃43;UseG1GC 来开启。这一方面的实战经验不多&＃xff0c;有相关使用经验的朋友欢迎分享。

 

此外&＃xff0c;还可以对新生代进行更细致的配置&＃xff0c;比如设置Eden 和 Suvivor 区的比例等&＃xff0c;和Newxx类似&＃xff0c;可以通过SuvivorRation设置比例。

 

 

其他 JVM 配置

 

可以使用 -XX:&＃43;DisableExplicitGC 选项来禁止显式的 System.gc 的调用。这个使用时需要评估后再使用。

 

所谓调优&＃xff0c;就是一个不断调整和优化的过程&＃xff0c;需要观察、配置、测试再如此重复。有相关经验的朋友欢迎留言补充&＃xff01;

 

说到底&＃xff0c;那上面的这些选项是要配置在哪里呢&＃xff1f; 我们前面提到 Tomcat 本质也是个普通的 Java 应用&＃xff0c;因此和一般的 Java 启动方式类似&＃xff0c;也是类似 

 

java -Xms100m -XX:&＃43;UseParallelOldGC 应用主类

 

通过这种形式来启动&＃xff0c;区别只是 Tomcat 将上述命令放到了文件中&＃xff0c;对应到不同的操作系统&＃xff0c;Windows下使用 bat文件&＃xff0c; Linux下使用 sh 文件。

 

所以我们的配置项也是加到这些文件中。

 

我们来看catalina.sh中实际启动时执行的命令&＃xff1a;

 

 

 

所以我们的选项可以加到 

JAVA_OPTS

CATALINA_OPTS

这些可选项中。

配置比较简单&＃xff0c;例如下面这样&＃xff1a;

 

 

配置的时候需要特别注意的是&＃xff0c;不要把前面已经有的配置冲掉&＃xff0c;比如

在配置JAVA_OPTS的时候&＃xff0c;要把前面已经配置的加上&＃xff0c;写起来是这样&＃xff1a;

JAVA_OPTS&＃61;"$JAVA_OPTS 新增的内容"