如何排查Tomcat 8连接性能问题？新服务器性能异常缓慢求助

哇，这情况确实有点反直觉——明明硬件拉满了，结果性能反而跳水，还好你已经缩小了范围到apt安装的Tomcat 8和tc Server的差异上，这给排查省了不少功夫。我来分享几个针对Tomcat连接性能的排查方向，你可以一步步来：

1. 先揪出Tomcat核心配置的差异 #

apt包管理安装的Tomcat和STS捆绑的tc Server（本质还是Tomcat），默认配置大概率不一样，这是最可能的罪魁祸首：

• 线程池配置对比：打开apt安装的Tomcat配置文件/etc/tomcat8/server.xml，再打开tc Server的server.xml，重点对比Connector标签里的这些参数：maxThreads（最大线程数）、minSpareThreads（最小空闲线程）、acceptCount（等待队列长度）、connectionTimeout（连接超时时间）。比如apt默认的maxThreads可能设得很低（比如200），而tc Server为了开发场景调得更高；如果connectionTimeout设得太短，会导致频繁断开重连，拖慢页面加载。
• HTTP协议类型检查：apt安装的Tomcat可能默认用了性能一般的NIO甚至BIO协议，而tc Server可能默认开启了更高效的NIO2或者APR/native库。你可以看Connector的protocol属性：org.apache.coyote.http11.Http11NioProtocol是NIO，org.apache.coyote.http11.Http11AprProtocol是APR（性能最优）。如果apt的Tomcat没装APR库，赶紧用sudo apt-get install libtcnative-1装上，然后修改protocol为APR试试。
• 压缩配置验证：静态资源和响应压缩能大幅减少传输量，apt默认可能没开，而tc Server可能默认开启了。在Connector标签里添加compression="on"、compressableMimeType="text/html,text/xml,text/plain,text/css,application/javascript"，重启Tomcat后再测试速度。

2. 对比JVM启动参数的差异 #

同样是Java 8，但Tomcat启动时的JVM参数可能天差地别，这直接影响性能：

• 查看apt Tomcat的JVM配置：通常在/etc/tomcat8/tomcat8.conf或者/etc/default/tomcat8里找JAVA_OPTS参数。你新服务器有256GB内存，apt默认可能只给了1-2GB的堆内存（比如-Xms1G -Xmx2G），这完全浪费了硬件！而tc Server在开发环境可能给了更大的堆，还开启了G1GC垃圾收集器。你可以把新服务器的JVM参数调优，比如：

  JAVA_OPTS="-Xms64G -Xmx64G -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+PrintGCDetails -Xloggc:/var/log/tomcat8/gc.log"
  

  堆内存可以根据你的实际应用情况调整，不用全占满256G，留一部分给系统。
• 分析GC日志：如果频繁Full GC会导致应用停顿，拖慢页面加载。给apt的Tomcat开启GC日志后，看看是否有长时间的GC停顿，再针对性调整GC参数。

3. 检查系统层面的资源限制 #

Ubuntu 18和14的默认系统参数可能有差异，会限制Tomcat的连接处理能力：

• 文件句柄限制：Tomcat处理HTTP连接需要打开文件句柄，Ubuntu默认的限制可能很低（比如1024）。用ulimit -n查看当前值，然后修改/etc/security/limits.conf，添加：

  tomcat soft nofile 65535
  tomcat hard nofile 65535
  

  重启Tomcat和系统后生效，确保Tomcat能打开足够的文件句柄。
• TCP内核参数调优：修改/etc/sysctl.conf里的TCP相关参数，提升连接处理效率：

  net.core.somaxconn = 1024  # 提升监听队列长度
  net.ipv4.tcp_tw_reuse = 1  # 重用TIME_WAIT状态的连接
  net.ipv4.tcp_fin_timeout = 30  # 缩短TIME_WAIT超时时间
  

  执行sudo sysctl -p让参数立即生效。

4. 用工具定位具体瓶颈 #

光看配置不够，得用工具抓实际的性能瓶颈：

• 系统资源监控：用htop或者top看CPU、内存的占用情况，如果某个线程CPU占满，可能是代码里的低效逻辑，但你说tc Server没问题，所以大概率是Tomcat配置问题。
• 线程栈分析：用jstack <tomcat-pid>抓取Tomcat的线程栈，看看是否有大量线程处于WAITING或BLOCKED状态，比如线程池不够导致请求排队，或者锁竞争。
• 压力测试对比：用ab工具做简单压力测试，比如：

  ab -n 100 -c 10 http://your-server/large-test-page
  

  对比apt Tomcat和tc Server的QPS、响应时间，看具体差异在哪里。
• 网络抓包：用Wireshark抓包，查看TCP三次握手时间、响应包大小、是否有丢包重传，排除网络层面的问题。

5. 最后验证应用兼容性 #

虽然tc Server没问题，但还是要排除应用本身的小概率问题：

• 检查应用代码是否依赖了Tomcat特定版本的非标准API？不过都是Tomcat8，这个可能性很低，但可以快速排查下。
• 检查应用的依赖库：是否有旧版本的Servlet API和Tomcat8的Servlet 3.1不兼容？或者某个第三方库在Java8下有性能问题？

按照这个顺序排查，应该很快能找到问题所在——毕竟你已经锁定了Tomcat安装方式的差异，核心就是配置和环境参数的不同。

内容的提问来源于stack exchange，提问作者mjames276