eG Monitoring
 

Accessing Stack Trace of the JVM Thresds Test using the STACK TRACE link

While viewing the measures reported by the JVM Thread test, you can also view the resource usage details and the stack trace information for all the threads, by clicking on the STACK TRACE link in the Measurements panel.

Note:

If the MODE set for the JVM Thread test is SNMP, the stack trace details may not be available.

A stack trace (also called stack backtrace or stack traceback) is a report of the active stack frames instantiated by the execution of a program. It is commonly used to determine what threads are currently active in the JVM, and which threads are in each of the different states - i.e., alive, blocked, waiting, timed waiting, etc.

Typically, when a Java application begins exhibiting erratic resource usage patterns, it often takes administrators hours, even days to figure out what is causing this anomaly - could it be owing to one/more resource-intensive threads being executed by the application? If so, what is causing the thread to erode resources? Is it an inefficient piece of code? In which case, which line of code could be the most likely cause for the spike in resource usage? To be able to answer these questions accurately, administrators need to know the complete list of threads that the application executes, view the stack trace of each thread, analyze each stack trace in a top-down manner, and trace where the problem originated.

eG Enterprise simplifies this seemingly laborious procedure by not only alerting administrators instantly to excessive resource usage by a target application, but also by automatically identifying the problematic thread(s), and providing the administrator with quick and easy access to the stack trace information of that thread; with the help of stack trace, administrators can effortlessly drill down to the exact line of code that requires optimization.

To access the stack trace information of a thread, click on the STACK TRACE link in the Measurements panel of Layer model.

The Thread diagnosis page comprising two panels will then appear. The left panel, by default, lists all the threads that the target application executes, starting with the threads that are currently live. Accordingly, the All Threads option is chosen by default from the Measurement list. If need be, you can override the default setting by choosing a different option from the Measurement list - in other words, instead of viewing the complete list of threads, you can choose to view threads of a particular type or which are in a particular state alone, by selecting a different Measurement thread diagnosis. For instance, to ensure that the left panel displays only those threads that are currently in a runnable state, select the Live threads option from the Measurement list. The contents of the left panel will change.

Also, the thread list in the left panel is by default sorted in the descending order of the Percent Cpu Time of the threads. This implies that, by default, the first thread in the list will be the thread that is currently active and consuming the maximum CPU. You can change the sort order by selecting a different option from the Sort by list in the Thread diagnosis page.

Typically, the contents of the right panel change according to the thread chosen from the left. Since the first thread is the default selection in the left panel, and this thread by default consumes the maximum CPU, we can conclude that the right panel will by default display the details of the leading CPU consumer. Besides the name and state of the chosen thread, the right panel will provide the following information:

  • Cpu Time : The amount of CPU processing time (in seconds) consumed by the thread during the last measurement period;
  • Percent Cpu Time: The percentage of time the thread was using the CPU during the last measurement period;
  • Blocked Count: The number of the times during the last measurement period the thread was blocked waiting for another thread;
  • Blocked Time: The total duration for which the thread was blocked during the last measurement period;
  • Percentage Blocked Time: The percentage of time (in seconds) for which the thread was blocked during the last measurement period;
  • Waited: The number of times during the last measurement period the thread was waiting for some event to happen (eg., wait for a thread to finish, wait for a timing event to finish, etc.);
  • Waited Time: The total duration (in seconds) for which the thread was waiting during the last measurement period;
  • Percentage Waited Time: The percentage of time for which the thread was waiting during the last measurement period.

In addition to the above details, the right panel provides the Stack Trace of the thread.

In the event of a sudden surge in the CPU usage of the target Java application, the Thread Diagnosis window will lead you to the CPU-intensive thread, and will also provide you with the Stack Trace of that thread. By analyzing the stack trace in a top-down manner, you can figure out which method/routine called which, and thus locate the exact line of code that could have contributed to the sudden CPU spike.

If the CPU usage has been increasing over a period of time, then, you might have to analyze the stack trace for one/more prior periods, so as to perform accurate root-cause diagnosis. By default, the Thread Diagnosis window provides the stack trace for the current measurement period only. If you want to view the stack trace for a previous measurement period, you will just have to select a different option from the Measurement Time list. By reviewing the code executed by a thread for different measurement periods, you can figure out out if the same line of code is responsible for the increase in CPU usage.