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

Question

Мы использовали Apache с JBOSS для размещения нашего Приложения, но обнаружили некоторые проблемы, связанные с обработкой потоков в mod_jk.

Наш сайт работает на сайтах с низким трафиком и имеет максимум 200-300 одновременно работающих пользователей в период максимальной активности нашего сайта. По мере роста трафика (не с точки зрения числа одновременных пользователей, а с точки зрения совокупных запросов, поступивших на наш сервер), сервер на длительное время прекращал обслуживать запросы, хотя и не падал, но не мог обслуживать запрос до 20 минут. Консоль сервера JBOSS показала, что 350 потоков были заняты на обоих серверах, хотя было достаточно свободной памяти, скажем, более 1-1,5 ГБ (использовались 2 сервера для JBOSS, которые были 64-разрядными, 4 ГБ ОЗУ выделено для JBOSS)

Чтобы проверить проблему, мы использовали JBOSS и Apache Web Consoles, и мы увидели, что поток показывался в состоянии 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.

Answer 1

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

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

Удачи!

Answer 2

Разверните собственный APR Apache в jboss / bin / native.

Отредактируйте свой jboss run.sh, чтобы убедиться, что он ищет собственные библиотеки в нужной папке.

Это заставит jboss использовать собственные соединители AJP, а не стандартные java.

Answer 3

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

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

Answer 4

Существует ошибка, связанная с утечкой потоков в исполнителе коннектора AJP, и решение объясняется здесь Пул потоков JJBSS AJP не освобождает незанятые потоки . Таким образом, соединения пула потоков AJP по умолчанию не имеют времени ожидания и будут сохраняться постоянно после установления. Надеюсь, это поможет,

Answer 5

У нас была эта проблема в среде Jboss 5. Причиной была веб-служба, которая отвечала дольше, чем позволяли Jboss / Tomcat. Это может привести к тому, что пул потоков AJP в конечном итоге исчерпает свои доступные потоки. Это тогда перестанет отвечать. Наше решение состояло в том, чтобы настроить веб-сервис для использования шаблона «запрос / подтверждение», а не шаблона «запрос / ответ». Это позволило веб-службе каждый раз отвечать в течение периода ожидания. Конечно, это не решает основную проблему конфигурации Jboss, но нам было проще сделать это в нашем контексте, чем настраивать jboss.

Answer 6

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

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

Answer 7

То, что мы сделали для решения этой проблемы, выглядит следующим образом:

 <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.