Obiettivo

Analizza i dump di thread Java di AEM utilizzando lo strumento IBM Thread Analyzer.

Passaggi

  1. Scarica e installa IBM Thread Analyzer (in breve IBM TDA)
  2. Cattura i dump di thread da un'istanza AEM soggetta a problemi di prestazioni.
  3. Apri i dump di thread in IBM TDA.
  4. Per visualizzare i dettagli di un dump di thread, seleziona il file nell'elenco, quindi fai clic sul pulsante "Dettaglio thread"*.
tda-threaddetail
  1. Ordina per "Profondità di stack" con gli stack più lunghi in alto.
tda-image1
  1. Esamina i thread con una profondità di stack di 10 o più righe.  Questi sono di solito i thread di maggior interesse.  Prendi appunti sui thread di interesse.
  2. Ordina per thread "Stato"
  3. Scorri verso il basso fino ai thread "Eseguibili". I thread eseguibili sono quelli che occupavano attivamente il tempo della CPU quando è stato effettuato il dump del thread.

Nota: Quando si esaminano i thread "Eseguibili", è possibile ignorare i thread elencati nella sezione Threads che si possono ignorare in fondo a questa pagina.

  1. Trova i thread eseguibili che fanno parte dell'applicazione, per esempio, thread di lavoro in background o di richiesta (i thread di richiesta hanno nomi come questo 127.0.0.1 [134702818187737] GET /content/sites/global/en/sitemap.static-delivery.httpd.html HTTP/1.1). Una volta trovati, fai clic su di loro uno ad uno.
  2. Per ogni thread di richiesta, è possibile sapere quando il browser dell'utente ha fatto la richiesta al server guardando la data e l'ora nel nome del thread.  Per esempio, nel nome del thread sopra, il timestamp (in formato millisecondo unix epoch) è 1347028187737.  Possiamo convertire quel numero d'epoca in una data / ora utilizzando www.epochconverter.com.  Ogni dump di thread mostra la data e l'ora in cui è stato effettuato.  È possibile prendere la differenza di tempo tra il tempo di richiesta e il tempo di dump del thread per vedere per quanto tempo una richiesta è stata attiva.
  3. Dopo aver esaminato i thread di richiesta, scorri tra gli altri thread "Eseguibili".  Una volta trovato un thread di interesse "Eseguibile", guarda il pannello centrale, "Thread in attesa".  I thread elencati sono in attesa che il thread selezionato rilasci un monitor.  Se non vedi nessun thread in attesa, il thread selezionato potrebbe essere ancora proprietario di un Lock (vedi le classi di implementazione di Lock per i dettagli). Ad esempio, con un ReentrantReadWriteLock non è possibile sapere quale thread è il sia il lock holder, in quanto i lock implementano più monitor internamente.  Quindi potrebbe essere necessario guardare il codice sorgente per abbinarlo ad un thread che potrebbe essere il lock holder.
  4. Se il thread aveva un lock o un monitor che molti altri thread aspettavano, coontrolla il resto dei dump di thread per vedere se è possibile trovare altri thread con lo stesso problema.  Verifica se lo stesso thread esiste ancora negli altri dump (in IBM TDA, puoi selezionare dump di thread multipli e fare clic sul pulsante "Confronta thread"* per visualizzare lo stato di un thread attraverso dump di thread multipli.
tda-comparethreads
  1. Vedi il Servizio raccolta nella schermata sottostante:
tda-Image2
  1. In questa vista è possibile vedere il thread attraverso più dump di thread per vedere se si tratta di un thread ad esecuzione lunga.  Fondamentalmente, se il thread è in stato Eseguibile attraverso discariche multiple e ha uno stack lungo, questo significa che si tratta di un thread ad esecuzione lunga.
  2. Se non hai trovato molto guardando i thread eseguibili, torna alla lista dei thread, seleziona un dump di thread e fai clic sul pulsante "Dettaglio monitor"* sul pannello superiore. IBM TDA aprirà una finestra che mostra una vista ad albero dei thread proprietari di monitor e dei loro thread in attesa. Nota: potrebbe visualizzare alcuni thread del pool di thread come il monitor del pool di thread del motore di servlet, i thread inattivi potrebbero essere ignorati.  Di solito si può dire che un thread è un thread inattivo di un pool perché la maggior parte delle volte hanno solo 10 righe di stack o meno.
tda-monitordetail
 
Utilizzo della CPU a livello di thread (solo piattaforma Linux):
  1. Se hai acquisito l’output "top -H -b -n1 -p <javapid>" otre alle immagini dei thread, puoi fare riferimento all’utilizzo della CPU a livello di thread.  Apri l’output superiore e ottieni l’id di processo dei thread che utilizzano la CPU.  Converti l’id del processo in esadecimale, quindi cerca il valore esadecimale nel corrispondente file delle immagini del thread.  L’id deve corrispondere al "nid" di uno dei thread.
  2. Se il thread corrispondente che utilizza la maggior parte della CPU è il “Thread VM” o un thread "GC", potresti avere un problema di memoria.  Ripeti lo stesso esercizio per più immagini di thread e output superiore e se c’è un pattern di questi thread che richiede tempo alla CPU, hai un problema di memoria.
  3. Se il problema di memoria è confermato, acquisisci un heap dump la prossima volta che si verifica il problema.  Vedi questo articolo per maggiori dettagli sull’acquisizione e l’analisi di heap dumps.

Thread che possono essere ignorati:

  • Thread VM: questo è un thread del sistema VM.
  • I thread che iniziano con thread di attività GC: questi sono i thread per la raccolta dei rifiuti.
  • I thread con nomi simili a - [1347028691218] in codice su java.net.PlainSocketImpl.socketAccept(Native Method): si tratta di threads del pool di thread del motore servlet in attesa di nuove connessioni.

Questo prodotto è concesso in licenza in base alla licenza di Attribuzione-Non commerciale-Condividi allo stesso modo 3.0 Unported di Creative Commons.  I post su Twitter™ e Facebook non sono coperti dai termini di Creative Commons.

Note legali   |   Informativa sulla privacy online