Apache с JBOSS, использующим AJP (mod_jk) предоставление скачков в количестве потока

У нас возникли похожие проблемы. Мы все еще работаем над решениями, но похоже, что здесь можно найти множество ответов:

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

Удачи!

Вам также следует обратить внимание на проблему JBoss Jira под названием «Потоки коннектора AJP, зависшие в состоянии CLOSE_WAIT»:

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

В tomcat 6 есть ошибка, которая была зарегистрирована недавно. Это касается HTTP-коннектора, но симптомы такие же.

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

Для устранения этой проблемы мы сделали следующее:

 <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 и гибернацией. Оптимизатор гибернации по умолчанию упростил нам жизнь, поэтому я считаю эту настройку очень важной.

Также удален пул соединений 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.