Problemi relativi al pool di thread Glassfish

Question

Utilizziamo Glassfish 3.0.1 e tempi di risposta molto lunghi; nell'ordine di 5 minuti per il 25% delle nostre richieste POST/PUT, nel momento in cui la risposta ritorna il bilanciamento del carico frontale è scaduto.

La mia teoria è che le richieste sono in coda e in attesa di un thread disponibile.

Il motivo per cui penso che questo è perché i registri di accesso rivelano che le richieste richiedono alcuni secondi per completare tuttavia il momento in cui vengono eseguite le richieste sono cinque minuti più tardi di quanto mi aspetterei.

Qualcuno ha qualche consiglio per il debug di cosa sta succedendo con i pool di thread? o quali dovrebbero essere le impostazioni ottimali per loro?

È necessario eseguire periodicamente un dump del thread o sarà sufficiente uno scarico singolo?

Answer 1

A prima vista, questo sembra avere molto poco a che fare con i threadpool stessi. Senza sapere molto circa il resto della configurazione della rete, qui ci sono alcune cose che vorrei controllare:

• C'è un/nodo non risponde morto nella piscina di bilanciamento del carico? Questo può far sì che tutte le richieste vengano provate su questo nodo fino a quando non falliscono a causa del timeout prima di essere reindirizzate all'altro nodo.
• C'è qualche problema con le connessioni iniziali tra il servizio di bilanciamento del carico e il server Glassfish? Può trattarsi di ricerche DNS lente o errate (sebbene il server debba memorizzare i risultati nella cache), un proxy mancante o qualche altro problema relativo alla rete.
• Avete controllato che gli orologi siano sincronizzati tra le macchine? Ciò potrebbe causare la sincronizzazione dei registri. 5min è un periodo di timeout piuttosto strano.

Se tutti questi venire a mani vuote, si può semplicemente avere un disadattamento di impedenza tra il bilanciamento del carico e il server web e potrebbe essere necessario aggiungere server web per gestire il carico. Il bilanciamento del carico dovrebbe essere in grado di darti un sacco di statistiche sul traffico in arrivo e su come si accumula.

Answer 2

L'utilizzo di threaddump è il modo migliore per eseguire il debug di ciò che accade nei threadpool. Si prega di prendere 3-4 threaddumps uno dopo l'altro con 1-2 secondi di spazio tra ciascun threaddump.

Da threaddump, è possibile trovare il numero di thread di lavoro in base al nome. Scopri le lunghe sequenze di thread dai vari threaddump.

È possibile utilizzare lo strumento TDA (http://java.net/projects/tda/downloads/download/tda-bin-2.2.zip) per analizzare i threaddump.

Answer 3

In genere questo comportamento si verifica se non sono stati configurati sufficienti thread di lavoro nel server. I valori predefiniti vanno da 15 a 100 thread nei webserver comuni. Tuttavia, se l'applicazione blocca i thread di lavoro del server (ad esempio attendendo le query), i valori predefiniti sono troppo bassi di frequente. È possibile aumentare il numero di worker fino a 1000 senza problemi (assicurare 64 bit). Controlla anche il numero di workthreads (a volte indicato come "max concurrent/open request") di qualsiasi server intermedio (ad esempio un proxy o un inoltro apache tramite mod_proxy).

Un altro errore comune è il software che invia richieste a se stesso (ad esempio, tenta di reindirizzare o inoltrare una richiesta) mentre blocca una richiesta in entrata.