Apache與JBOSS使用AJP（mod_jk）給出了線程數的峰值

Question

我們使用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。

Answer 1

我們遇到了類似的問題。 我們仍在研究解決方案，但看起來很多答案可以在這里找到：

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

祝好運！

Answer 2

在jboss / bin / native下部署Apache本機APR。

編輯你的jboss run.sh以確保它在正確的文件夾中查找本機庫。

這將強制jboss使用本機AJP連接器trhead而不是默認的純java連接器。

Answer 3

您還應該看看JBoss Jira問題，標題為“在CLOSE_WAIT狀態中掛起的AJP連接器線程”：

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

Answer 4

我們在Jboss 5環境中遇到了這個問題。 原因是Web服務的響應時間比Jboss / Tomcat允許的時間長。 這將導致AJP線程池最終耗盡其可用線程。 然后它會停止響應。 我們的解決方案是調整Web服務以使用Request / Acknowledge模式而不是Request / Respond模式。 這允許Web服務每次在超時期限內響應。 雖然這並沒有解決Jboss的底層配置問題，但是我們在上下文中比調整jboss更容易。

Answer 5

我們為解決這個問題所做的工作如下：

 <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狀態。

Answer 6

最近提交的tomcat 6中存在一個錯誤。 這是關於HTTP連接器但症狀聽起來相同。

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

Answer 7

有一個與AJP連接器執行程序泄漏線程相關的錯誤，這里解釋了解決方案Jboss AJP線程池未釋放空閑線程 。 總之，默認情況下，AJP線程池連接沒有超時，並且一旦建立就會永久保留。 希望這可以幫助，