1. Inicio
  2. Pregunta y respuesta
  3. Apache con JBOSS usando AJP (mod_jk) dando picos en el conteo de hilos

Apache con JBOSS usando AJP (mod_jk) dando picos en el conteo de hilos

2009-12-04 20 views
5

Utilizamos Apache con JBOSS para alojar nuestra aplicación, pero encontramos algunos problemas relacionados con el manejo de hilos de mod_jk.Apache con JBOSS usando AJP (mod_jk) dando picos en el conteo de hilos

Nuestro sitio web tiene menos sitios web de tráfico y tiene un máximo de 200-300 usuarios concurrentes durante el tiempo de actividad pico de nuestro sitio web. A medida que crece el tráfico (no en términos de usuarios concurrentes, sino en términos de solicitudes acumulativas que llegaron a nuestro servidor), el servidor dejó de atender solicitudes por mucho tiempo, aunque no se bloqueó, pero no pudo atender la solicitud hasta 20 minutos. La consola del servidor JBOSS mostró que 350 hilos estaban ocupados en ambos servidores aunque hubo decir suficiente memoria libre, más de 1-1,5 GB (Se han usado 2 servidores para JBOSS que fueron de 64 bits, 4 GB de RAM asignada para JBOSS)

Para comprobar el problema estábamos usando JBOSS y Apache Web Consoles, y estábamos viendo que el hilo se mostraba en estado S durante tanto tiempo como minutos, aunque nuestras páginas tardan alrededor de 4-5 segundos en ser atendidas.

Cogimos el volcado de subprocesos y descubrimos que los subprocesos estaban en su mayoría en estado de espera, lo que significa que estaban esperando indefinidamente. Estos hilos no eran de nuestras clases de aplicación, sino del puerto AJP 8009.

Podría alguien ayudarme en esto, ya que alguien más también podría tener este problema y lo resolvió de alguna manera. En caso de que se requiera más información, házmelo saber.

También es mejor mod_proxy que usar mod_jk, o hay algunos otros problemas con mod_proxy que pueden ser fatales para mí si cambio a mod__proxy?

Las versiones que he utilizado son los siguientes:

Apache 2.0.52 
JBOSS: 4.2.2 
MOD_JK: 1.2.20 
JDK: 1.6 
Operating System: RHEL 4

Gracias por la ayuda.

Chicos !!!! Finalmente encontramos la solución con la configuración mencionada anteriormente. Es uso de APR y se menciona aquí: http://community.jboss.org/thread/153737. Su problema es mencionado correctamente por muchas personas en las respuestas a continuación, es decir, problema de conector. Anteriormente hicimos una solución temporal al configurar hibernación y aumentar el tiempo de respuesta. La solución completa es APR.

Fuente

2009-12-04 Ashish Jain

Respuesta

0

Lo que hicimos para la clasificación de este problema a cabo es el siguiente:

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

Los parámetros anteriores aseguraron que los subprocesos de trabajo no están bloqueados por lucene y la búsqueda de hibernación. El optimizador predeterminado de hibernación hizo nuestra vida más fácil, por lo que considero que este ajuste es muy importante.

También se eliminó la agrupación de conexiones C3P0 y se utilizó la agrupación de conexiones JDBC incorporada, por lo que comentamos a continuación la sección.

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

Después de hacer todo esto, hemos sido capaces de reducir considerablemente el tiempo que una rosca AJP estaba tomando para servir una petición y roscas empezaron a venir a estado R después de servir la solicitud es decir, en el estado S.

Fuente

2010-02-04 07:52:30

0

Estábamos teniendo este problema en un entorno Jboss 5. La causa fue un servicio web que tardó más en responder de lo que permitía Jboss/Tomcat. Esto causaría que el grupo de subprocesos AJP eventualmente agotara sus hilos disponibles. Entonces dejaría de responder. Nuestra solución fue ajustar el servicio web para usar un patrón de solicitud/confirmación en lugar de un patrón de solicitud/respuesta. Esto permitió que el servicio web respondiera dentro del tiempo de espera cada vez. De acuerdo, esto no resuelve el problema de configuración subyacente de Jboss, pero nos resultó más fácil hacerlo en nuestro contexto que sintonizar jboss.

Fuente

2012-07-09 19:16:07

2

Implementa la APR nativa de Apache en jboss/bin/native.

Edite su jboss run.sh para asegurarse de que está buscando las librerías nativas en la carpeta correcta.

Esto forzará a jboss a usar trheads de conector AJP nativos en lugar de los puros java predeterminados.

Fuente

2012-10-19 18:57:45 Dan

0

Hay un error relacionado con el ejecutor del conector AJP con fuga de hilos y la solución se explica aquí Jboss AJP thread pool not released idle threads. En resumen, las conexiones de grupo de subprocesos AJP de forma predeterminada no tienen tiempo de espera y persistirán permanentemente una vez establecidas. Espero que esto ayude,

Fuente

2016-09-03 12:56:45 user3277258

Cuestiones relacionadas

 Cuestiones relacionadas