Lettura dei dump dei thread

Best practice per lo sviluppo di applicazioni > Monitoraggio delle applicazioni ThingWorx > Monitoraggio e risoluzione dei problemi relativi alle prestazioni > Esecuzione lenta dei servizi > Utilizzo dei dati di thread per monitorare l'esecuzione lenta dei servizi > Lettura dei dump dei thread

Ogni dump di thread inizia con la data e l'ora in cui viene acquisita l'istantanea.

Full thread dump taken at Thu Aug 1 07:19:59 EDT 2019

I dump dei thread JVM mostrano lo stack di chiamate coinvolto in tutte le operazioni del server in esecuzione su un thread specifico. Sebbene un errore frequente visualizzi anche uno stack di chiamate, quest'ultimo non indica un errore sul server. Uno stack di chiamate mostra in ordine inverso il modo in cui sono stati richiamati metodi specifici. Vedere l'esempio seguente:

"http-nio-8080-exec-8" tid=0x114 in RUNNABLE
Blocked: 32[-1ms], Waited: 99[-1ms]
User CPU: 109ms
- synchronizer <0x4206a205> (a java.util.concurrent.ThreadPoolExecutor$Worker)
at sun.management.ThreadImpl.dumpThreads0(Native Method)
at sun.management.ThreadImpl.dumpAllThreads(Unknown Source)
at com.thingworx.support.utilities.Stacktrace.dumpThreadInfo(Stacktrace.java:70)
at com.thingworx.support.utilities.Stacktrace.dumpAllStacks(Stacktrace.java:64)
- locked <0x4cdd9461> (a java.lang.Class)
at com.thingworx.support.utilities.Stacktrace.dumpAllStacks(Stacktrace.java:38)
- locked <0x4cdd9461> (a java.lang.Class)
at com.thingworx.support.utilities.SupportToolsTemplate.DumpAllThreads(SupportToolsTemplate.java:202)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.thingworx.common.processors.ReflectionProcessor.processService(ReflectionProcessor.java:261)
at com.thingworx.handlers.ReflectionServiceHandler.processService(ReflectionServiceHandler.java:50)
at com.thingworx.things.Thing.processServiceRequestDirect(Thing.java:7886)
at com.thingworx.things.Thing.processAPIServiceRequest(Thing.java:7824)
at com.thingworx.webservices.BaseService.handleInvoke(BaseService.java:3077)
at com.thingworx.webservices.BaseService.service(BaseService.java:356)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:742)
…

Nello stack di chiamate vengono utilizzati i metodi di estensione degli strumenti di supporto per ottenere informazioni sui thread. Il metodo dumpAllStacks richiama il metodo dumpThreadInfo, che richiede le informazioni sui thread dalla piattaforma Java incorporata.

Il nome del servizio che richiama queste classi Java è generalmente elencato sotto lo stack di chiamate. In questo caso il servizio DumpAllThreads viene elencato come parte dello stack di chiamate. Il metodo processService richiama sempre i servizi personalizzati. La verifica dei servizi elencati dopo processService nello stack di chiamate consente di ottenere il thread su cui viene eseguito un servizio specifico.

Di seguito sono elencati i possibili stati di un thread.

• RUNNABLE - Stato positivo. Indica che il thread dispone di tutte le risorse necessarie per eseguire le operazioni.

• BLOCKED - Indica che il thread è in attesa di un oggetto in un altro thread prima di poter completare l'operazione.

• TIME_WAITING - Indica che il thread è in attesa che un sincronizzatore acceda a una risorsa o di un input aggiuntivo (simile allo stato WAITING)

• WAITING - Indica che il thread non sta eseguendo alcuna operazione ed è in attesa di ulteriore input. Questo è lo stato normale di default per il 99% dei thread di un'acquisizione.

Se si raccoglie l'output utilizzando il comando jstack Java anziché l'estensione Support Tool, molti thread vengono visualizzati nello stato BLOCKED. Tuttavia i thread si trovano nello stato TIME_WAITING. Per alcuni tipi di thread può essere lo stato di default. Per evitarlo, eseguire il comando jstack come sudo -u <Utentetomcat> jstack <pid>.