1. casa
  2. Domanda e risposta
  3. Apache con JBOSS usando AJP (mod_jk) dando picchi nel conteggio dei thread

Apache con JBOSS usando AJP (mod_jk) dando picchi nel conteggio dei thread

2009-12-04 13 views
5

Abbiamo usato Apache con JBOSS per ospitare la nostra applicazione, ma abbiamo riscontrato alcuni problemi relativi alla gestione dei thread di mod_jk.Apache con JBOSS usando AJP (mod_jk) dando picchi nel conteggio dei thread

Il nostro sito Web rientra in siti Web a basso traffico e ha un numero massimo di 200-300 utenti simultanei durante il tempo di attività di picco del nostro sito Web. Man mano che il traffico aumenta (non in termini di utenti concorrenti, ma in termini di richieste cumulative che arrivano al nostro server), il server ha interrotto le richieste a lungo, anche se non si è arrestato ma non è stato in grado di soddisfare la richiesta fino a 20 minuti. La console del server JBOSS mostrava che 350 thread erano occupati su entrambi i server anche se c'era abbastanza memoria libera, più di 1-1,5 GB (erano usati 2 server per JBOSS 64 bit, 4 GB RAM allocati per JBOSS)

Per verificare il problema, stavamo usando JBOSS e Apache Web Consoles e stavamo vedendo che il thread veniva mostrato in stato S per un tempo pari a minuti, sebbene le nostre pagine richiedessero circa 4-5 secondi per essere pubblicate.

Abbiamo preso il dump del thread e abbiamo scoperto che i thread erano per lo più in stato di ATTESA il che significa che stavano aspettando indefinitamente. Questi thread non erano delle nostre classi di applicazione ma della porta AJP 8009.

Qualcuno potrebbe aiutarmi in questo, come qualcun altro potrebbe anche avere questo problema e risolto in qualche modo. Nel caso in cui siano necessarie ulteriori informazioni, fammi sapere.

Inoltre mod_proxy è meglio dell'utilizzo di mod_jk oppure ci sono altri problemi con mod_proxy che possono essere fatali per me se si passa a mod__proxy?

Le versioni che ho usato sono i seguenti:

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

Grazie per l'aiuto.

Ragazzi !!!! Abbiamo finalmente trovato la soluzione alternativa con la configurazione di cui sopra. È l'uso di APR ed è menzionato qui: http://community.jboss.org/thread/153737. Il problema è stato correttamente menzionato da molte persone nelle risposte sotto il problema del connettore. In precedenza abbiamo risolto il problema temporaneo configurando l'ibernazione e aumentando i tempi di risposta. La correzione completa è APR.

fonte

2009-12-04 Ashish Jain

risposta

0

Quello che abbiamo fatto per l'ordinamento questo problema fuori è il seguente:

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

I parametri sopra riportati garantiscono che i thread di lavoro non vengano bloccati dalla ricerca di lucene e ibernazione. L'ottimizzazione predefinita dell'ibernazione ha reso la vita facile, quindi considero questa impostazione molto importante.

Inoltre, è stato rimosso il pool di connessioni C3P0 e utilizzato il pool di connessioni JDBC incorporato, pertanto abbiamo commentato la sezione seguente.

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

Dopo aver fatto tutto questo, siamo stati in grado di ridurre notevolmente il tempo che una filettatura AJP portava a servire una richiesta e discussioni iniziate venire a stato R dopo che serve la richiesta cioè nello stato S.

fonte

2010-02-04 07:52:30

0

Stavamo avendo questo problema in un ambiente Jboss 5. La causa era un servizio Web che richiedeva più tempo per rispondere rispetto a quello consentito a Jboss/Tomcat. Ciò farebbe sì che il pool di thread AJP esaurisse i thread disponibili. Quindi smetterebbe di rispondere. La nostra soluzione era di adattare il servizio web per utilizzare un modello di richiesta/riconoscimento piuttosto che un modello di richiesta/risposta. Ciò ha consentito al servizio Web di rispondere ogni volta entro il periodo di timeout. Certo, questo non risolve il problema di configurazione di fondo di Jboss, ma è stato più facile per noi farlo nel nostro contesto rispetto alla messa a punto di jboss.

fonte

2012-07-09 19:16:07

2

Distribuire l'APR nativo Apache sotto jboss/bin/native.

Modifica il tuo jboss run.sh per assicurarti che stia cercando le librerie native nella cartella giusta.

Ciò obbligherà jboss a utilizzare i connettori del connettore AJP nativo anziché quelli puramente java predefiniti.

fonte

2012-10-19 18:57:45 Dan

0

C'è un bug relativo al connettore del connettore AJP che perde thread e la soluzione è spiegata qui Jboss AJP thread pool not released idle threads. In sintesi, le connessioni del pool di thread AJP per impostazione predefinita non hanno timeout e rimarranno permanentemente una volta stabilite. Spero che questo aiuti,

fonte

2016-09-03 12:56:45 user3277258

Problemi correlati

 Problemi correlati