我们使用Apache和JBOSS来托管我们的应用程序,但是我们发现了一些与mod_jk的线程处理相关的问题。
我们的网站属于流量较低的网站,在我们网站的最高活动时间内,最多有200-300名并发用户。随着流量的增长(不是就并发用户而言,而是就来到我们服务器的累积请求而言),服务器停止长时间处理请求,尽管它没有崩溃,但是在20分钟之前无法提供请求。 JBOSS服务器控制台显示350个线程在两台服务器上都忙,尽管有足够的可用内存,超过1-1.5 GB(使用JBOSS的2台服务器为64位,为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。其问题正如许多人在下面的答案中正确提到的那样,即连接器问题。之前我们通过配置hibernate和增加响应时间来进行临时解决。完整修复是APR。
答案 0 :(得分:4)
我们遇到了类似的问题。我们仍在研究解决方案,但看起来很多答案可以在这里找到:
http://www.jboss.org/community/wiki/OptimalModjk12Configuration
祝你好运!答案 1 :(得分:2)
在jboss / bin / native下部署Apache本机APR。
编辑你的jboss run.sh以确保它在正确的文件夹中查找本机库。
这会强制jboss使用本机AJP连接器trhead而不是默认的纯java连接器。
答案 2 :(得分:1)
您还应该看看JBoss Jira问题,标题为“在CLOSE_WAIT状态中挂起的AJP连接器线程”:
答案 3 :(得分:0)
我们为解决这个问题所做的工作如下:
<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搜索阻止。 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状态。
答案 4 :(得分:0)
最近提交的tomcat 6中存在一个错误。这是关于HTTP连接器但症状听起来相同。
答案 5 :(得分:0)
我们在Jboss 5环境中遇到了这个问题。原因是Web服务的响应时间比Jboss / Tomcat允许的时间长。这将导致AJP线程池最终耗尽其可用线程。然后它会停止响应。我们的解决方案是调整Web服务以使用Request / Acknowledge模式而不是Request / Respond模式。这允许Web服务每次在超时期限内响应。虽然这并没有解决Jboss的底层配置问题,但是我们在上下文中比调整jboss更容易。
答案 6 :(得分:0)
有一个与AJP连接器执行程序泄漏线程相关的错误,解决方案在这里解释Jboss AJP thread pool not released idle threads。总之,默认情况下,AJP线程池连接没有超时,并且一旦建立就会永久保留。希望这会有所帮助,