Tomcat调优与死锁排查

1 Tomcat基础安全优化、基础性能优化

• 四种基础安全优化：

• 1、降权启动：以普通用户的身份启动tomcat
• 2、telnet管理端口保护：修改server.xml文件中的管理端口8005为其他端口
• 3、AJP连接端口禁用：注释server.xml文件中AJP协议一行
• 4、禁用管理端：删除webapps下除ROOT目录外其他目录，并清空ROOT下的初始代码（有的说要修改tomcat账号密码，其实直接禁用管理端就行，反正要放新代码，后台服务器也可以管理）

• 两种基础性能优化

• 1、屏蔽DNS查询：禁止DNS方向解析，修改server.xml配置文件中enableLookups=“false”
• 2、JVM调优：优化catalina.sh脚本

2 排查java进程占用CPU过高的思路

2.1 锁死问题排查

2.1.1 问题描述：

生产环境下某台tomcat7服务器，在刚发布的时候一切都很正常，在运行一段时间后就出现CPU占用很高的问题，基本上是负载一天比一天高。诸如此类问题，请排查！

top命令查询，发现每个逻辑CPU都进程占用率（us）都很高，且java进程CPU占用百分比超过100%

2.1.2 问题分析

1、正在做GC（java的内存垃圾回收机制），也可能是内部程序出现死锁
2、查看访问量，并发请求
3、java支持多线程，当每个CPU都在工作时，可能导致java进程持续占用大量CPU
4、查看tomcat优化的配置，是否需要进一步优化
5、程序代码有问题，出现死循环，可能性极大

2.1.3、排查思路

我们可以尝试通过jstack命令来精确定位出现错误的代码段，从而拿给开发排查。

1. 查找CPU占用高的进程PID

top 或者 htop命令查找CPU占用高的进程PID
top -d 1或者top -H
或者(找到tomcat的进程）
ps -ef | grep tomcat | grep tomcat

2. 定位有问题的线程的PID

进程创建的线程会具有和线程一致的“线程组ID”，同时各个线程户会获得其自身的线程ID（TID）

• 查看线程ID
  ps -T -p PID
  -T参数开启线程查看，此行命令可列出该PID进程创建的所有线程，但ps命令只能静态查看，
• top和htop命令可以动态查看动态变化
  调用top命令的-H选项，会列出所有线程
top -H -p PID指定进程号动态查看其所有线程情况，或者strace -p 进程的PID查看这个进程所有系统调用（可以找到哪个PID号的线程对CPU占用高）

3. 继续打印该线程的堆栈信息（找出有问题的代码块）

printf "%x\n" 线程的PID
#将有问题的线程的PID号转换成16进制格式
jstack 进程的PID | grep 线程PID号的十六进制格式 -A 30 #过滤出有问题的线程的堆栈信息，找出问题代码块，将代码复制发给开发排查

3 tomcat配置调优详解

• 主要从三个方面：内存，并发，缓存

3.1 内存调优

主要是配置tomcat对JVM参数的设置，在catalina.sh脚本中设置java_OPTS参数

当服务器内存为32G时，可以采用以下配置

JAVA_OPTS='-server -Xms8192m -Xmx8192m -XX:MaxNewSize=256m -XX:PerSize=256m -XX:MaxPermSize=512m'

-sever：表示启用jdk的server运行模式
Xms：设置JVM初始堆内存的大小
Xmx：设置JVM最大堆内存的大小，过大会触发linux OOM机制（out of memory机制，当某进程占用内存过大，为保证系统正常运行，linux会杀掉内存占用的进行）
XX:PermSize：设置堆内存持久代初始值大小，默认是物理内存的1/64
XX:MaxPermSize：设置持久代最大值，默认物理内存1/4
Xmm1g:设置堆内存年轻代大小

将最大堆内存和初始堆内存设置为相等；堆内存设置过大，JVM可用内存多，但GC过程会长时间处于暂停；最大堆内存最好设置为不超过物理内存的50%

3.2 并发和缓存优化

• 对server.xml文件进行参数优化配置

<Connector port="8080"
    protocol="HTTP/1.1"
    maxHttpHeaderSize="8192"    #最大的http请求头部大小
    maxThreads="1000"           #线程数最大值
    minSpareThreads="100"       #最少保留100个线程处于空闲状态
    maxSpareThreads="1000"      #最多保留1000个线程处于空闲状态
    enableLookups="false"       #禁止DNS方向解析
    compression="on"            #打开文件传输的压缩功能
    compressionMinSize="2048"   #当数据大于2KB才会进行压缩
    compressableMimeType="text/html,text/xml,test/javascript,text/css,text/plain"       #待压缩的文件类型
    connectionTimeout="20000"   #连接超时时间20秒
    URIEncoding="utf-8"         #URL统一编码格式支持中文
    acceptCount="1000"          #监听端口的等待队列最大数，超过此数字服务器会直接拒绝此次请求（最大并发=该值+maxThreads,在这里为2000）
    redirectPort="8443"         #用于基于安全通道的场景，把用户请求转发到SSL的redirectPort端口
    disableUploadTimeout="true"
/>

3.3 运行模式优化

模式	优缺点	适用场景
BIO (blockig I/O)	阻塞式I/O操作的java API；每个请求需要创建一个线程来处理，不能处理高并发的场景，性能最低	tomcat7以下版本默认是BIO
NIO (non-blocking I/O)	基于缓冲区，并能提供非阻塞I/O操作的java API：一个请求一个线程，客户端的连接请求会被注册到多路复用器上，当多路复用器轮询到连接有I/O请求时才启动一个线程进行处理	tomcat8及以上默认是NIO，比BIO拥有更好的并发运行性能，使用于连接数多且连接短的架构，jdk1.4之后支持
AIO	以JNI的形式调用apache http服务器的核心动态连接库来处理文件读取或网络传输操作，提高对静态文件的处理性能；I/O模型为异步非阻塞，一个有效请求一个线程，从操作系统级别来解决异步的IO问题，但tomcat本身不能直接修改，需要安装apr和native	使用于高并发的场景，用于连接数目多且长连接的架构，jdk7之后开始支持

随线程不断增多，BIO模式性能越来越差，错误率和响应时间都会增加，吞吐量和每秒传输速率都在下降，而NIO和APR模式基本变化不大，生产环境的模式选择，需要进行具体的压力测试

3.3.1 运行模式查看：

• tomcat日志可以看出来