Apache+Tomcat 通信出现问题。不明确的错误信息。关闭托管在 Tomcat 下的网站

Question

设置：
Fedora 8
Apache 2.2.8
Tomcat 5.5.8
Apache 使用 AJP 转发请求。

问题：
经过一段时间后（根本没有常数，可能在一两个小时之间，或者一天或几天之间）Tomcat 将关闭。它要么停止响应，要么提供通用的“服务暂时不可用”。

诊断：
有两台服务器的设置相同。一个是流量较高的网站（每秒几个请求），另一个是低流量网站（每隔几分钟就有几个请求）。这两个网站是完全不同的代码库，但它们表现出相似的问题。

在第一台服务器上，当问题发生时，所有线程都开始慢慢被占用，直到达到限制（MaxThreads 200）。那时服务器不再响应（并且在很长一段时间后出现服务不可用页面）。

在第二台服务器上，出现问题时，请求需要很长时间，完成后您只能看到服务不可用页面。

除了提到 MaxThreads 问题之外，Tomcat 日志没有指出可能导致此问题的任何特定问题。

但是，在 Apache 日志中，我们看到了涉及 AJP 的随机消息。这是我们看到的随机消息示例（无特定顺序）：

[error] (70007)The timeout specified has expired: ajp_ilink_receive() can't receive header
[error] (104)Connection reset by peer: ajp_ilink_receive() can't receive header
[error] proxy: AJP: disabled connection for (localhost)
[error] ajp_read_header: ajp_ilink_receive failed
[error] (120006)APR does not understand this error code: proxy: read response failed from 127.0.0.1:8009 (localhost)
[error] ap_proxy_connect_backend disabling worker for (localhost)

我们在更高流量的服务器上注意到的另一件奇怪的事情是，就在问题开始发生之前，数据库查询所用的时间比以前长得多（2000-5000 毫秒，而通常为 5-50 毫秒）。在 MaxThreads 消息出现之前，这只会持续 2-4 秒。我假设这是服务器突然处理太多数据/流量/线程的结果。

背景信息：
这两个服务器已经运行了很长时间没有问题。在此期间，系统实际上是使用两个 NIC 设置的。他们将内部和外部流量分开。网络升级后，我们将这些服务器移至单个 NIC（出于安全/简单的原因，我们建议这样做）。更改之后，服务器开始出现这些问题。

解决方案：
显而易见的解决方案是返回两个 NIC 的设置。这样做的问题是它会导致网络设置出现一些复杂情况，并且似乎忽略了这个问题。我们更愿意尝试让它在单个 NIC 设置上运行。

谷歌搜索各种错误消息并没有提供任何有用的信息（旧解决方案或与我们的问题无关）。

我们已经尝试调整各种超时，但这只会使服务器在死亡之前运行时间稍长。

我们不确定在哪里可以进一步诊断问题。我们仍然在抓紧问题可能是什么：

1) AJP 和 Tomcat 的设置不正确或过时（即已知错误？）
2) 网络设置（两个 NIC 对一个 NIC）导致混乱或吞吐量问题。
3) 网站本身（没有通用代码，没有使用平台，只有带有 servlet 和 JSP 的基本 Java 代码）

更新 1：
按照 David Pashley 的有用建议，我在问题期间进行了堆栈跟踪/线程转储。我发现所有 200 个线程都处于以下状态之一：

"TP-Processor200" daemon prio=1 tid=0x73a4dbf0 nid=0x70dd waiting for monitor entry [0x6d3ef000..0x6d3efeb0]
at  oracle.jdbc.pool.OracleConnectionCacheImpl.getActiveSize(OracleConnectionCacheImpl.java:988)
- waiting to lock <0x7e3455a0> (a oracle.jdbc.pool.OracleConnectionCacheImpl)
[further stack trace removed for brevity]

"TP-Processor3" daemon prio=1 tid=0x08f142a8 nid=0x652a waiting for monitor entry [0x75c7d000..0x75c7ddb0]
at oracle.jdbc.pool.OracleConnectionCacheImpl.getConnection(OracleConnectionCacheImpl.java:268)
- waiting to lock <0x7e3455a0> (a oracle.jdbc.pool.OracleConnectionCacheImpl)
[further stack trace removed for brevity]

奇怪的是，所有 200 个线程中只有一个线程处于这种状态：

"TP-Processor2" daemon prio=1 tid=0x08f135a8 nid=0x6529 runnable [0x75cfe000..0x75cfef30]
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.read(SocketInputStream.java:129)
at oracle.net.ns.Packet.receive(Unknown Source)
at oracle.net.ns.DataPacket.receive(Unknown Source)
at oracle.net.ns.NetInputStream.getNextPacket(Unknown Source)
at oracle.net.ns.NetInputStream.read(Unknown Source)
at oracle.net.ns.NetInputStream.read(Unknown Source)
at oracle.net.ns.NetInputStream.read(Unknown Source)
[further stack trace removed for brevity]

可能是该线程中的 Oracle 驱动程序强制所有其他线程等待它完成。出于某种原因，它必须停留在这种读取状态（服务器永远不会自行恢复，它需要重新启动）。

这表明它必须与服务器和数据库之间的网络或数据库本身有关。我们正在继续进行诊断工作，但任何提示都会有所帮助。

Answer 1

事实证明，这个版本的 Oracle 驱动程序（classes12 - 很旧）有各种导致死锁的错误（如上面引用的 TP-Processor2 状态所示）。直到我们切换到新环境后，它才变得活跃。升级到最新版本 (ojdbc14) 已解决主服务器上的问题。

Answer 2

从描述中，我认为问题可能是由于数据库查询花费的时间太长。如果查询需要更长的时间，请求将需要更长的时间，因此您将同时运行更多的查询。如您所见，您的 tomcat 线程已用完。当您解决数据库问题时，您应该没问题。

• 使用 jstack 或使用 kill -3 $process_id 获取堆栈跟踪。看看你的线程在它死后在做什么。如果他们都在等待数据库，那是我的理论的一个很好的指针。他们可能都在等待某个锁。
• 安装 LambdaProbe。了解您的 tomcat 正在做什么是非常宝贵的。
• 升级你的 tomcat。5.5.8 太旧了。我认为他们现在是 5.5.27。

Answer 3

将 connectionTimeout 和 keepAliveTimeout 添加到 /etc/tomcat7/server.xml 中的 AJP 连接器。

<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" 
           connectionTimeout="10000" keepAliveTimeout="10000" />

有关 AJP 连接器的信息，请访问https://tomcat.apache.org/tomcat-7.0-doc/config/ajp.html

• connectionTimeout = 此连接器在接受连接后等待显示请求 URI 行的毫秒数。AJP 协议连接器的默认值为 -1（即无限）。

• keepAliveTimeout = 此连接器在关闭连接之前等待另一个 AJP 请求的毫秒数。默认值是使用已为 connectionTimeout 属性设置的值。

如果 connectionTimeout 和 keepAliveTimeout 值未定义，则 AJP 连接将无限期保持活动状态。导致许多线程，默认最大线程数为 200。

我建议安装 psi-probe - Apache Tomcat 的高级管理器和监视器，从 Lambda Probe 分叉出来。https://code.google.com/p/psi-probe/