java - Tomcat 压力测试超时

Question

我目前正在调查以下系统的问题:

• 3.2 GHz 8 核机器，24 GB 内存
• Debian 6.0.2
  • ulimit -n 4096
  • ulimit -Sn 4096
  • ulimit -Hn 65535
• Tomcat 6.0.28
  • -Xmx20g
• MySQL 5.0.51a(通过 hibernate 和一些手动 JDBC 查询)
  • 还有相当大的缓存空间

我正在远程测试对服务器的最常见请求，每分钟 2000 个请求。测试工具是最新的jMeter。平均响应时间约为 65 毫秒，最小值为 35 毫秒，最大值为 4000 毫秒(在极少数情况下，但这是有原因的)。

就我观察 htop 而言，系统规范足以满足每分钟至少 3 倍的请求。 (平均 CPU:25%，RAM:22GB 中的 5 个)服务器本身始终可以访问。 (在运行测试时不断地 Ping 它。)

重要的是，每个请求都会导致对本地 tomcat 的 3 个额外请求，其中第二个最终获得所需的数据，最后一个用于统计:jMeter(1) -> RESTeasy-Service(2) -> ?-Service(2) -> Data-Service(2) -(new Thread)> Statistic-Service(2)

(1) 是我的 jMeter 测试服务器，远离 (2)，这是 tomcat 服务器。是的，架构可能有点奇怪，但这不是我的错。 ^^

我在 server.xml 中将线程管理切换为池。将最大线程从默认值 200 设置为 1000，将空闲线程从 4 设置为 10。我注意到并发线程的数量几乎没有减少，反而稳步上升到 tomcat 的最大值似乎。 htop 在 tomcat 停止时报告 160 个线程。刚开始时大约460。 (服务似乎开始了一些......)在以每分钟 2000 个请求访问服务器几个小时(有时更少)后，htop 表示有 1400 个任务。这似乎 是我开始在 jMeter 中获得超时的时间点。由于这非常耗时，我没有观看它一千次，因此不能保证这就是原因，但这几乎就是发生的事情。

主要问题:

1. 数学告诉我并发使用的线程数永远不应超过 600。(34 个请求 * 4 个请求 * 4 秒 = 544，甚至更少，但估计 600 应该没问题)。据我理解线程池的思想，未使用的线程应该在空闲时间过长时被释放和停止。还有办法让我获得一千个空闲(？)线程吗？这样可以吗？

2. 在其中一个请求处理器中手动启动的线程是否会拒绝释放 tomcat 线程？

3. 难道不应该有任何日志消息告诉我 tomcat 无法为请求创建/获取线程吗？

4. 还有其他想法吗？我在这方面工作的时间太长了，现在 tomcat 耗尽了它的线程池似乎是这些奇怪超时的唯一正当理由。但也许有人有另一个提示。

提前致谢，特别是如果你最终能救我于此...

Answer 1

经过数小时和数天的令人兴奋的工作后，我发现当 Tomcat 达到其线程限制时会发生超时，而我们正处于这 3 个本地连接开口的中间。我想如果它一旦达到该限制，一个线程正在等待另一个线程打开，而前一个线程不会关闭时不会发生这种情况。在德语中，我称之为 Teufelskreis。 ^^

无论如何，解决方案是将最大线程数提高到一个荒谬的高数字:

<Executor name="tomcatThreadPool" namePrefix="catalina-exec-" maxThreads="10000" minSpareThreads="10"/>

我知道这不应该是要走的路，但不幸的是我们都知道我们的架构有些不切实际而且没有人有时间对其进行更改。

希望对大家有所帮助。 =)