1. 首頁
  2. 問答
  3. Apache與JBOSS使用AJP（mod_jk）給線程數產生尖峯

Apache與JBOSS使用AJP（mod_jk）給線程數產生尖峯

2009-12-04 101 views
5

我們使用Apache和JBOSS來託管我們的應用程序，但是我們發現了一些與線程處理mod_jk有關的問題。Apache與JBOSS使用AJP（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。

來源

2009-12-04 Ashish Jain

回答

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狀態的要求，即後。

來源

2010-02-04 07:52:30

0

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

來源

2012-07-09 19:16:07

2

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

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

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

來源

2012-10-19 18:57:45 Dan

相關問題

 相關問題