Core Java

jstat – Analysis

jstat is a simple utility tool, that is present in JDK to provide JVM performance-related statistics like garbage collection, compilation activities. The major strength of jstat is its ability to capture these metrics dynamically when JVM is running without any pre-requisite instrumentation. What do we mean by it? Say for example if you want to capture garbage collection related statistics, you need to pass below arguments before you start the JVM:

1
-Xlog:gc*:file={file-path}

This argument will enable GC logs and print them in the specified file path. Say suppose you haven’t passed this argument, then GC related statistics will not be generated. This is where jstat can come handy. Dynamically you can connect to JVM and capture GC, compilation related statistics as shown below.

How to launch jstat?

Execute below command. It’s a simple option to launch jstat.

1
jstat -gc -t 11656 10000 30

-gc: garbage collection related statistics will be printed

-t timestamp since JVM was started will be printed

11656: target JVM process Id

10000: statistics will be printed every 10,000 milliseconds (i.e. 10 seconds).

30: statistics will be printed for 30 iterations. Thus, the above option will cause the JVM to print metrics for 300 seconds (i.e. 10 seconds x 30 iterations).

(Note besides -gc, you can pass various other options to generate different data sets. For more details on different options, you refer here.)

Data generated by jstat

When you launch jstat with above options, here is the output that will be generated:

Fig: jstat output

Timestamp – time since the start time of the target JVM in seconds.

S0C – Survivor 0 region capacity in KB

S1C – Survivor 1 region capacity in KB

S0U – Survivor 0 region utilized space in KB

S1U – Survivor 1 region utilized space in KB

EC – Eden region capacity in KB

EU – Eden region’s utilized space in KB

OC – Old region capacity in KB

OU – Old region’s utilized space in KB

MC – Metaspace region capacity in KB

MU – Metaspace region utilized space in KB

CCSC – Compressed Class space regions capacity in KB

CCSU – Compressed Class space regions utilized space in KB

YGC – Number of Young GC events that have occurred so far

YGCT – Amount of Young GC time spent so far

FGC – Number of Full GC events that have occurred so far

FGCT – Amount of Full GC time spent so far

GCT – total amount of GC time spent so far (basically YGCT + FGCT)

How to interpret jstat output?

Equipped with this information let’s try to interpret the first line printed by the jstat tool in the above example:

Fig: jstat output’s first line
Timestamp

 

 

Time since JVM has been started in seconds

 

 

= 164.9 seconds
Young generation capacity

 

 

Young Generation is made up of Eden region, Survivor 0, Survivor 1. Thus, capacity is:

 

 

S0C + S1C + EC

 

= 116224.0 + 116224.0 + 116736.0

 

= 349184 kb

= 341 mb

 

Young generation utilized size

 

 

 

 

S0U + S1U + EU

 

= 0 + 1520 + 68761.8

 

= 70281.8 kb

= 68.63 mb

Old generation capacity OC = 431616 kb

 

= 421.5 mb

 

Old generation utilized size

 

 

OU

 

 

= 280502.5 kb

 

= 273.93 mb

 

Metaspace capacity MC

 

 

= 32384 kb

 

= 31.62 mb

 

Metaspace utilized size MU = 31155.5 kb

 

= 30.42mb

Young GC Count

 

 

YGC

 

 

= 29

 

 

Time spent in Young GC YGCT

 

 

= 0.836 seconds

 

 

Total time spent in GC GCT = 2.27 seconds

 

 

Tool to analyze jstat output

One challenge with jstat is you need to manually analyze the generated statistics. It will be tedious, as you can see just to understand/interpret one single line it takes a quite long time. You can use GCeasy tool, which can parse jstat output and generate insightful graphs and metrics. Here is the jstat analysis report generated by GCeasy by analyzing above jstat output.

Limitation of jstat

There are certain limitations with jstat:

(a).  jstat doesn’t provide rich detailed information about GC activities. It only provides just enough information. Example from jstat you will not know:

  1. If multiple GC events are reported within one-time sample, we wouldn’t know what the pause time of each GC event was.
  2. How much time is spent in Sys (i.e. kernel), user (i.e. java layer)
  3. How many GC threads are working and how much time they are taking?
  4. One GC event has several subphases (like an initial mark, clean-up, remark, concurrent mark….). That break down of information isn’t available.
  5. How many bytes are reclaimed by each GC event

(b). Sometimes data reported by jstat can be misleading as well.

If you would like to do accurate GC analysis, GC logs are the more reliable way.

Published on Java Code Geeks with permission by Ram Lakshmanan, partner at our JCG program. See the original article here: jstat – Analysis

Opinions expressed by Java Code Geeks contributors are their own.

Ram Lakshmanan

Ram Lakshmanan developed world's finest DevOps tools: GCeasy.io, fastThread.io, HeapHero.io. Every single day, millions & millions of people in North America—bank, travel, and commerce—use the applications that Ram Lakshmanan has architected. Ram is an acclaimed speaker in major conferences on scalability, availability, and performance topics. Recently, he has founded a startup, which specializes in troubleshooting performance problems.
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Back to top button