Apache 与 JBOSS 使用 AJP (mod_jk) 在线程数中产生峰值答案

【问题标题】：Apache with JBOSS using AJP (mod_jk) giving spikes in thread countApache 与 JBOSS 使用 AJP (mod_jk) 在线程数中产生峰值
【发布时间】：2009-12-04 10:11:49
【问题描述】：

我们使用 Apache 和 JBOSS 来托管我们的应用程序，但我们发现了一些与 mod_jk 的线程处理相关的问题。

我们的网站属于低流量网站，在我们网站的活动高峰期最多有 200-300 个并发用户。随着流量的增长（不是并发用户，而是到达我们服务器的累积请求），服务器停止服务请求很长时间，虽然它没有崩溃，但直到 20 分钟才能处理请求。 JBOSS 服务器控制台显示两台服务器上都有 350 个线程忙，尽管有足够的空闲内存，例如超过 1-1.5 GB（使用了 2 个 64 位的 JBOSS 服务器，为 JBOSS 分配了 4 GB RAM）

为了检查问题，我们使用了 JBOSS 和 Apache Web 控制台，我们看到线程在 S 状态下显示的时间长达几分钟，尽管我们的页面需要大约 4 到 5 秒才能提供服务。

我们进行了线程转储，发现线程大多处于 WAITING 状态，这意味着它们正在无限期地等待。这些线程不是我们的应用程序类，而是 AJP 8009 端口。

有人可以帮助我吗，因为其他人可能也遇到了这个问题并以某种方式解决了它。如果需要更多信息，请告诉我。

mod_proxy 也比使用 mod_jk 更好，或者如果我切换到 mod__proxy，mod_proxy 还有一些其他问题对我来说可能是致命的？

我使用的版本如下：

Apache 2.0.52
JBOSS: 4.2.2
MOD_JK: 1.2.20
JDK: 1.6
Operating System: RHEL 4

感谢您的帮助。

伙计们！！！！我们终于找到了上述配置的解决方法。它是使用 APR 并在此处提及：http://community.jboss.org/thread/153737。许多人在下面的答案中正确提到了它的问题，即连接器问题。早些时候，我们通过配置休眠和增加响应时间来临时解决问题。完整的修复是 APR。

【问题讨论】：

标签： java multithreading apache jboss ajp

【解决方案1】：

我们遇到了类似的问题。我们仍在研究解决方案，但似乎可以在这里找到很多答案：

http://www.jboss.org/community/wiki/OptimalModjk12Configuration

祝你好运！

【讨论】：

【解决方案2】：

在 jboss/bin/native 下部署 Apache 原生 APR。

编辑您的 jboss run.sh 以确保它在正确的文件夹中查找本机库。

这将强制 jboss 使用本地 AJP 连接器 trheads 而不是默认的纯 Java 连接器。

【讨论】：

【解决方案3】：

您还应该查看 JBoss Jira 问题，标题为“AJP Connector Threads Hung in CLOSE_WAIT Status”：

https://jira.jboss.org/jira/browse/JBPAPP-366

【讨论】：

【解决方案4】：

我们为解决这个问题所做的工作如下：

 <property name="hibernate.cache.use_second_level_cache">false</property>


 <property name="hibernate.search.default.directory_provider">org.hibernate.search.store.FSDirectoryProvider</property>
    <property name="hibernate.search.Rules.directory_provider">
        org.hibernate.search.store.RAMDirectoryProvider 
    </property>

    <property name="hibernate.search.default.indexBase">/usr/local/lucene/indexes</property>

    <property name="hibernate.search.default.indexwriter.batch.max_merge_docs">1000</property>
    <property name="hibernate.search.default.indexwriter.transaction.max_merge_docs">10</property>

    <property name="hibernate.search.default.indexwriter.batch.merge_factor">20</property>
    <property name="hibernate.search.default.indexwriter.transaction.merge_factor">10</property>

 <property name ="hibernate.search.reader.strategy">not-shared</property>   
 <property name ="hibernate.search.worker.execution">async</property>   
 <property name ="hibernate.search.worker.thread_pool.size">100</property>  
 <property name ="hibernate.search.worker.buffer_queue.max">300</property>  

 <property name ="hibernate.search.default.optimizer.operation_limit.max">1000</property>   
 <property name ="hibernate.search.default.optimizer.transaction_limit.max">100</property>  

 <property name ="hibernate.search.indexing_strategy">manual</property>

以上参数确保工作线程不会被 lucene 和 hibernate search 阻塞。 hibernate 的默认优化器让我们的生活变得轻松，因此我认为这个设置非常重要。

还移除了 C3P0 连接池，使用了内置的 JDBC 连接池，因此我们在下面的部分进行了评论。

 <!--For JDBC connection pool (use the built-in)-->


 <property   name="connection.provider_class">org.hibernate.connection.C3P0ConnectionProvider</property>
    <!-- DEPRECATED very expensive property name="c3p0.validate>-->
    <!-- seconds -->

在完成所有这些之后，我们能够大大减少 AJP 线程处理请求所花费的时间，并且线程在处理请求后开始进入 R 状态，即 S 状态。

【讨论】：

【解决方案5】：

最近提交的 tomcat 6 中有一个错误。这是关于 HTTP 连接器的，但症状听起来是一样的。

https://issues.apache.org/bugzilla/show_bug.cgi?id=48843#c1

【讨论】：

【解决方案6】：

我们在 Jboss 5 环境中遇到了这个问题。原因是 Web 服务的响应时间超过了 Jboss/Tomcat 允许的时间。这将导致 AJP 线程池最终耗尽其可用线程。然后它将停止响应。我们的解决方案是调整 Web 服务以使用请求/确认模式而不是请求/响应模式。这允许 Web 服务每次都在超时期限内响应。当然，这并不能解决 Jboss 的底层配置问题，但在我们的上下文中，这比调整 jboss 更容易。

【讨论】：

【解决方案7】：

有一个与 AJP 连接器执行器泄漏线程相关的错误，解决方案在此处解释 Jboss AJP thread pool not released idle threads。总之，AJP 线程池连接默认没有超时，一旦建立就会永久存在。希望这会有所帮助，

【讨论】：