在Linux中，部署及优化Tomcat

最新推荐文章于 2024-09-07 15:32:10 发布

ssg18336543974

最新推荐文章于 2024-09-07 15:32:10 发布

阅读量1k

点赞数 18

文章标签： linux tomcat 运维

本文链接：https://blog.csdn.net/ssg18336543974/article/details/140614781

版权

tomcat概述

自 2017 年 11月编程语言排行榜 Java 占比 13%,高居榜首，Tomcat 也一度成为 Java开发人员的首选。其开源、占用系统资源少、跨平台等特性深受广大程序员喜爱。本章主要学习如何部署 Tomcat 服务，根据生产环境实现多个虚拟主机的配置，最后的重点是进行压测，根据压测结果如何优化 Tomcat 服务及常见的内存溢出如何处理。

tomcat介绍

自从 JSP 发布之后,推出了各式各样的 JSP 引擎。Apache Group 在完成 GNUJSP1.0的开发以后，开始考虑在 SUN 的 JSWDK 基础上开发一个可以直接提供 Web 服务的 JSP服务器，当然同时也支持 Servlet, 这样 Tomcat 就诞生了。
Tomcat是 Apache 软件基金会(Apache Software Foundation)Jakarta 项目中的一个核心项目，由Apache、Sun 和其他一些公司及个人共同开发而成。其被 JavaWorld 杂志的编辑选为 2001 年度最具创新的 Java 产品，同时它又是 Sun 公司官方推荐的 Servlet和 JSP 容器，因此 Tomcat 越来越多的受到软件公司和开发人员的喜爱。由于有了 Sun 的参与和支持，最新的 Servlet 和 JSP 规范总是能在 Tomcat 中得到体现，Tomcat5 支持最新的 Servlet 2.4 和 JSP 2.0 规范。因为 Tomcat 技术先进、性能稳定、免费,因而深受 Java爱好者的喜爱并得到了部分软件开发商的认可，成为目前比较流行的Web应用服务器。
Tomcat 服务器是一个免费的开放源代码的Web 应用服务器,属于轻量级应用服务器,在中小型系统和并发访问用户不是很多的场合下被普遍使用，是开发和调试JSP 程序的首选。对于一个初学者来说，可以这样认为，当在一台机器上配置好 Apache 服务器，可利用它响应 HTML(标准通用标记语言下的一个应用)页面的访问请求。实际上，Tomcat 是Apache 服务器的扩展，但运行时它是独立运行的，所以当运行 Tomcat 时，它实际上作为一个与 Apache 独立的进程单独运行的。
当配置正确时，Apache 为HTML页面服务，而Tomcat 实际上运行 JSP 页面和Servlet。Tomcat 和 IS 等 Web 服务器一样，具有处理 HTML 页面的功能，另外它还是个 Servlet 和 JSP 容器，独立的 Servlet 容器是 Tomcat 的默认模式。不过，Tomcat 处理静态 HTML 的能力不如 Apache 服务器。

tomcat核心组件

通常意义上的 Web 服务器接受请求后，只是单纯地响应静态资源(如 HTML 文件、图片文件等)，不能在后端进行一定的处理操作。Tomcat是 Apache 下的一个子项目，它具备 Web 服务器的所有功能，不仅可以监听接受请求并响应静态资源，而且可以在后端运行特定规范的 Java 代码 Servlet，同时将执行的结果以 HTML 代码的形式返回客户端。Tomcat 由一系列的组件构成，其中核心的组件有三个。
Web 容器:完成 Web 服务器的功能。
Servlet 容器:名字为catalina，用于处理 Servlet 代码。
JSP 容器:用于将 JSP 动态网页翻译成 Servlet 代码。

tomcat请求处理

Tomcat 具体的处理请求过程如下所示。
用户在浏览器中输入网址 localhost:8080/testndexjsp,请求被发送到本机端口 8080被在那里监听的 Coyote HTTP/1.1 Connector 获得;
Connector 把该请求交给它所在的Service 的 Engine(Container)来处理，并等待Engine 的回应;
Engine 获得请求 localhost/testindex.jsp，匹配所有的虚拟主机 Host;
Engine 匹配到名为 localhost的 Host(即使匹配不到也把请求交给该 Host 处理，因为该 Host 被定义为该 Engine 的默认主机)，名为localhost 的 Host 获得请求/testindex.jsp，匹配它所拥有的所有 Context。Host 匹配到路径为/test 的 Context(如果匹配不到就把该请求交给路径名为“"的 Context 去处理);
path=“/test"的 Context 获得请求/index.jsp，在它的 mapping table 中寻找出对应的Servlet。Context 匹配到 URLPattem为*.jsp的 Servlet，对应于JspServlet 类;
构造 HttpServletRequest 对象和 HttpServletResponse 对象,作为参数调用 JspServlet的 doGet()或 doPost(),执行业务逻辑、数据存储等;
Context 把执行完之后的 HttpServletResponse 对象返回给 Host;

>Host 把 HttpServletResponse 对象返回给 Engine;
Engine 把 HttpServletResponse 对象返回 Connector;
Connector把 HttpServletResponse 对象返回给客户 Browser。

tomcat服务部署

下载并安装jdk

在部署 Tomcat 服务之前需要先部署好实验环境，本章实验环境的具体要求如表 8-1所示

在部署 Tomcat 之前必须安装好 JDK，因为 JDK是 Tomcat 运行的必要环境。JDK 的安装相对比较简单，版本有很多，本章选择基于linux64 位 RPM 版本。
下载完安装包后，将其上传到服务器/root目录下，执行安装命令。

上面显示安装完成，idk安装目录在/usriava/dk1.8.0 171-amd64，，编辑/etc/profile文件，设置idk的环境变量。具体操作如下。

安装启动tomcat

安装tomcat服务

从 Tomcat官网下载 apache-tomcat-9.0.8.tar.gz稳定版本,将安装包解压后移动 Tomcat目录到/usr/local 下面，然后执行/usr/local/tomcat/bin/startup.sh 命令启动 Tomcat 即可。具体操作如下。

浏览器打开 http://192.168.9.236:8080 进行访问会出现 Tomcat 主页，如图 8.1 所示。

优化tomcat服务启动时间

查看日志会发现 Tomcat 第一次启动很慢，默认情况下都需要几十秒。修改 JDK 参数可以改善该状况，打开/usrjava/jdk1.8.0_171-amd64fjre/ib/security/java.security 文件，找到如下内容:securerandom.source=file:/devrandom修改成securerandom.source=file:/dev/urandom。然后重启 Tomcat 就会发现启动时间变短很多。

tomcat目录结构

执行 ll/usr/local/tomcat命令即可査看 Tomcat 安装后目录结构，如下图 8.2 所示.。

Tomcat 各目录的作用具体如下所示。
bin 目录:用于存放启动和关闭 Tomcat 的脚本文件，比较常用的是catalina.sh、startup.sh、shutdown.sh 三个文件。
conf目录:用于存放 Tomcat 服务器的各种配置文件，比较常用的是 server.xml、
context.xml、tomcat-users.xml、web.xml 四个文件。
lib 目录:用于存放 Tomcat 服务器的jar 包，一般不作任何改动，除非连接第三方服务，比如 redis，那就需要添加相对应的jar 包。
logs 目录:用于存放 Tomcat 日志。
temp 目录:用于存放 Tomcat 运行时产生的文件。
webapps 目录:用于存放项目资源的目录。
work 目录:是 Tomcat 工作目录，一般清除Tomcat 缓存的时候会使用到。

tomcat配置与优化

虚拟主机配置

很多时候公司会有多个项目需要运行，那么肯定不可能是一台服务器上运行多个Tomcat 服务，这样会消耗太多的系统资源。此时，就需要使用到 Tomcat 虚拟主机。例如现在新增两个域名 www.test.com 和 bbs.test.com，希望通过这两个域名访问到不同的项目内容。

创建www和bbs项目目录和文件

执行下面的命令，可以创建 www 和 bbs 项目目录和文件。

修改tomcat主配置文件

容。
修改 Tomcat 主配置文件/usr/local/tomcat/conf/server.xml，在</Host>下面增加如下内

虚拟主机访问测试

客户端绑定两个域名需要写入本机hosts，Tomcat 默认端口是8080

使用浏览器访问 http://www.test.com:8080，页面效果如图 8.3 所示

tomcat优化

Tomcat 默认安装下的缺省配置并不适合生产环境，它会频繁出现假死现象需要重启只有通过不断压测优化才能让它最高效率稳定的运行。优化主要包括三方面，分别为操作系统优化(内核参数优化)，Tomcat配置文件参数优化，Java虚拟机(JVM)调优。其中最难理解的就是 JVM 调优。系统优化本章不介绍，本章将配合jmeter 压测工具进行调优前和调优后的数据进行比较。

tomcat配置文件参数优化

关于 Tomcat 主配置文件 server.xml 里面很多默认的配置项，并不能满足业务需求，常用的优化参数如下。
maxThreads:Tomcat 使用线程来处理接收的每个请求，这个值表示 Tomcat 可创建的最大的线程数，默认值是 200。
minSpareThreads:最小空闲线程数，Tomcat启动时的初始化线程数，表示即使没有人使用也开这么多空线程等待，默认值是10。

maxSpareThreads:最大备用线程数，一旦创建的线程超过这个值，Tomcat就会关闭不再需要的 socket 线程。默认值是-1(无限制)，一般不需要指定。
URIEncoding:指定 Tomcat 容器的 URL 编码格式，Tomcat 语言编码格式这块不如其它 Web 服务器软件配置方便，需要分别指定。
connnectionTimeout:网络连接超时，单位:毫秒，设置为0表示永不超时，这样设置有隐患的。通常默认 20000毫秒就可以。
enableLookups:是否反查域名，以返回远程主机的主机名，取值为:tne或false，如果设置为false，则直接返回IP地址，为了提高处理能力，应设置为false。
disableUploadTimeout:上传时是否使用超时机制。应设置为tmue。
connectonUploadTimeout:上传超时时间，毕竟文件上传可能需要消耗更多的时间，该参数需要根据自己的业务雷要自行调整,以使Semvlet有较长的时间来完成它的执行需要与上一个参数一起配合使用才会生效。
acceptCount:指定当所有可以使用的处理请求的线程都被使用时，可传入连接请求的最大队列长度，超过这个数的请求将不子处理，默认为100个。
compression:是否对响应的数据进行 GZIP 压缩，off 表示禁止压缩、on 表示允许压缩(文本将被压缩)、force 表示所有情况下都进行压缩，默认值为of。压缩数据后可以有效的减少页面的大小，一般可以减小13左右，因而节省带宽。
compressionMinSize:表示压缩响应的最小值，只有当响应报文大小大于这个值的时候才会对报文进行压缩，如果开启了压缩功能，默认值就是2048
compressableMimeType:压缩类型，指定对哪些类型的文件进行数据压缩
noCompressionUserAgents="gozila,traviata":对于以下的浏览器，不启用压缩。
如果已经对代码进行了动静分离，静态页面和图片等数据就不需要Tomcat处理了，那么也就不需要在 Tomcat 中配置压缩了。因为这里只有一台Tomcat 服务器，而且压测的是Tomcat 首页，会有图片和静态资源文件，所以这里启用压缩。
以上是一些常用的配置参数,还有好多其它的参数设置,还可以继续深入的优化，HTTPConnector与AJPConnector 的参数属性值，可以参考官方文档的详细说明进行学习。链接地址 http:/omcatapache.org/tomcat-9.0-docconfig/http.html, 下面开始对 Tomcat 配置文件优化进行前后的对比。

jmeter压测工具

要压测，首先学习关于imeter压测工具基本的使用方法。执行步骤如下
(1)客户端安装JDK
从 Oracle 官方下载 JDK 软件，JDK 安装过程直接下一步即可。因为本章中所使用的客户端是 Windows 10，所以 JDK 使用 jdk-8u102-windows-x64 版本。
(2)运行jmeter 软件
本章中是使用的jmeter 软件版本为apache-jmeter-3.1,双击运行apache-jmeter-3.1.rar压缩包->bin 目录->ApacheJMeter.jar 文件即可打开jmeter 软件，如图 8.5 所示。

(3)打开压测脚本进行压测
点击左上角文件->打开->选择压测脚本

4、修改tomcat配置

修改配置参数后压测

重新启动 Tomcat 服务器,jmeter 还是继续保持同样的参数进行压测,优化后压测截图,如 8.9 所示。

3.Java 虚拟机(JVM)调优
Tomcat 启动命令行中的优化参数，就是 JVM 的优化。Tomcat是Java 程序，运行在 JVM 之上，因为它的启动其实也只是一个 Java 命令行，我们需要对这个 Java 的启动命令行进行调优。不管是 YGC 还是FuGC、GC 都会导致程序运行中断，正确的选择不同的 GC 策略，调整 JVM、GC 的参数，可以极大的减少由于 GC 工作而导致的程序运行中断方面的问题，进而适当的提高 Java 程序的工作效率。但是调整 GC 是一个极为复杂的过程，由于各个程序具备不同的特点，如Web 和GUI程序就有很大区别(Web 可以适当的停顿,但 GUI停顿是客户无法接受的),而且由于运行在各个机器上的配置不同(主要 CPU个数，内存不同)，所以使用的 GC 种类也会不同。下面对JVM 参数做比较详细的说明。
Tomcat 的启动参数位于安装目录 $(JAVA HOME}bin 目录下，Linux 操作系统就是catalina.sh 文件。Java OPTS 就是用米设置JVM 相关运行参数的变量，下面具体看 JVM常用参数详解。

-server:一定要作为第一个参数，只要Tomcat 是运行在生产环境中，这个参数必须给加上，不然后面的参数不会生效。
-Xms:表示 Java 初始化堆的大小，-Xms 与-Xmx 设成一样的值，避免 JVM 反复重新申请内存，导致性能大起大落，默认值为物理内存的1/64，默认(MinHeapFreeRatio参数可以调整)空余堆内存小于 40%时，JVM 就会增大堆直到-Xmx的最大限。
-Xmx;表示最大Java堆大小，当应用程序需要的内存超出堆的最大值时虚拟机就会提示内存溢出，并且导致应用服务崩溃，因此一般建议堆的最大值设置为物理内存的最大值的 50%。
-XX:NewSize:设置新生代内存大小。
-XX:MaxNewSize:设置最大新生代内存大小。
-XX:PemmmSize:设置持久代内存大小。
-XX:MaxPermSize:设置最大值持久代内存大小，永久代不属于堆内存，堆内存只包含新生代和老年代。
XX:+AggressiveOpts:作用如其名(aggressive)，若启用这个参数，则每当JDK版本升级时，JVM 都会使用最新加入的优化技术(如果有的话)。
XX:+UseBiasedLocking:启用一个优化了的线程锁，要知道在 appserver，每个 http请求就是一个线程，有的请求短有的请求长，就会有请求排队的现象，甚至还会出现线程阻塞，这个优化了的线程锁使得 appserver 内对线程处理自动进行最优调配。
XX:+DisableExplicitGC:在程序代码中不允许有显示的调用"System.gc()”。每次在操作结束时手动调用 System.gc()一下，付出的代价就是系统响应时间严重降低，就和关于 Xms，Xmx 里的原理一样，这样去调用 GC 会导致系统的 JVM 大起大落。
-XX:+UseParNewGC:对新生代采用多线程并行回收，这样收得快。需要注意的是在最新 JVM 版本中,当使用-XX:+UseConcMarkSweepGC 时,-XX:UseParNewGC 会自动开启。因此,如果年轻代的并行 GC 不想开启,可以通过设置 -XX:-UseParNewGC来关掉。
-XX:MaxTenuringThreshold:设置垃圾最大年龄。如果设置为0的话，则新生代对象不经过 Survivor区，直接进入老年代。对于老年代比较多的应用(需要大量常驻内存的应用)，可以提高效率。如果将此值设置为一个较大值，则新生代对象会在Survvor

区进行多次复制，这样可以增加对象在新生代的存活时间，增加在新生代即被回收的概率，减少Fu GC的频率，这样做可以在某种程度上提高服务稳定性。该参数只有在串行 GC 时才有效，这个值的设置是根据本地的jprofiler 监控后得到的一个理想的值，不能一概而论原搬照抄。
-XX:+CMSParallelRemarkEnabled:在使用 UseParNewGC 的情况下，尽量减少mark 的时间。
-XX:+UseCMSCompactAtFulCollection:在使用concurrent gc的情况下，防止memoryfragmention，对live object 进行整理，使memory 碎片减少。
-XX:LargePageSizelnByles:指定 Javaheap 的分页页面大小，内存页的大小不可设置过大，会影响 Perm 的大小。
-XX:+UseFastAccessorMethods:使用get，set方法转成本地代码，原始类型的快速优化。
XX:+UseCMSInitiatingOccupancyOnly:只有在 oldgeneration 在使用了初始化的比例后 concurent collector 启动收集。
-Duser.timezone=Asia/Shanghai:设置用户所在时区。
.Djava.awt.headless=true:这个参数一般我们都是放在最后使用。有时我们会在我们的 J2EE 工程中使用一些图表工具，如:ifreechart，用于在Web 网页输出GIF/JPG等流，在Windows 环境下，一般我们的 app server 在输出图形时不会碰到什么问题,但是在 Linux/Unix 环境下经常会碰到一个 exceplion 导致你在 Wndows 开发环境下图片正常显示，可是在 Linux/Unix下却显示不出来，因此加上这个参数以免避这样的情况出现。
-Xmn:新生代的内存空间大小,注意:此处的大小是(eden+2survivorspace).与 jmap-heap 中显示的Newgen 是不同的。整个堆大小=新生代大小 + 老生代大小 + 永久代大小。在保证堆大小不变的情况下，增大新生代后，将会减小老生代大小。此值对系统性能影响较大，Sun 官方推荐配置为整个堆的3/8。
-XX:CMSInitiatingOccupancyFraction:当堆满之后，并行收集器便开始进行垃圾收集。例如，当没有足够的空问来容纳新分配或提升的对象。对于CMS收集器，长时间等待是不可取的，因为在并发垃圾收集期问应用持续在运行(并且分配对象)。因此，为了在应用程序使用完内存之前完成垃圾收集周期,CMS收集器要比并行收集器更先启动。

因为不同的应用会有不同对象分配模式，JVM会收集实际的对象分配(和释放)的运行时数据，并且分析这些数据，来决定什么时候启动一次CMS垃圾收集周期。这个参数设置有很大技巧上满足基本(Xmx-Xmn)*(100-CMSInitiatingOccupancyFraclion)/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关联在一起。
-XX:+CMSIncrementalMode:该标志将开启CMS 收集器的增量模式。增量模式经常暂停CMS过程，以便对应用程序线程作出完全的让步，因此，收集器将花更长的时问完成整个收集周期。因此，只有通过测试后发现正常CMS周期对应用程序线程干扰太大时，才应该使用增量模式。由于现代服务器有足够的处理器来适应并发的垃圾收集，所以这种情况发生得很少，用于但CPU情况。
-XX:NewRatio:年轻代(包括Eden和两个 Survivor 区)与年老代的比值(除去持久代)，-XX:NewRatio=4 表示年轻代与年老代所占比值为1:4，年轻代占整个堆栈的115，Xms=Xmx 并且设置了Xmn 的情况下，该参数不需要进行设置。
-XX:SurvivorRatio:Eden 区与 Survivor 区的大小比值，设置为8，表示 2个Sunvivor区(JVM 堆内存年轻代中默认有2个大小相等的Sunvivor区)与1个Eden 区的比值为2:8，即1个 Survivor 区占整个年轻代大小的 1/10。
-XX:+UseSerialGC:设置串行收集器。
-XX:+UseParallelGC:设置为并行收集器。此配置仅对年轻代有效。即年轻代使用并行收集，而年老代仍使用串行收集。
-XX:+UseParallelOldGC:配置年老代垃圾收集方式为并行收集，JDK6.0开始支持对年老代并行收集。
.XX:ConcGCThreads:早期 JVM 版本也叫-XX:ParallelCMSThreads,定义并发 CMS过程运行时的线程数。比如value=4意味着CMS周期的所有阶段都以4个线程来执行。尽管更多的线程会加快并发CMS过程，但其也会带来额外的同步开销。因此，对于特定的应用程序，应该通过测试来判断增加CMS线程数是否真的能够带来性能的提升。如果还标志未设置，JVM 会根据并行收集器中的-XX:ParallelGCThreads 参数的值来计算出默认的并行 CMS 线程数。
-XX:ParallelGCThreads:配置并行收集器的线程数，即:同时有多少个线程一起进行垃圾回收，此值建议配置与 CPU 数目相等。
-XX:OldSize:设置JVM 启动分配的老年代内存大小，类似于新生代内存的初始大小-XX:NewSize。
以上就是一些常用的配置参数，但是有些参数是可以被替代的，配置思路需要考虑的是Java 提供的垃圾回收机制。虚拟机的堆大小决定了虚拟机花费在收集垃圾上的时间和频度。收集垃圾能够接受的速度和应用有关，应该通过分析实际的垃圾收集的时间和频率来调整。假如堆的大小很大，那么完全垃圾收集就会很慢，但是频度会降低。假如您把堆的大小和内存的需要一致，完全收集就很快，但是会更加频繁。调整堆大小的目的是最小化垃圾收集的时间，以在特定的时间内最大化处理客户的请求。在基准测试的时候，为确保最好的性能，要把堆的大小设大，确保垃圾收集不在整个基准测试的过程中出现。
测试前,先还原 Tomcat 到默认的配置文件,重启后压测一组优化前压测截图,如图 8.10所示。