Activities

November 2016
M T W T F S S
« Aug   Jan »
 123456
78910111213
14151617181920
21222324252627
282930  

Collecting the JVM data for identifying the bottleneck

WE all are developing jave application for various area as it is one of the secure and non-hackle platform. So it’s consider is most secured programming platform to choose. Here One of our servers went heavily loaded and we did not find any specific reasons to happen this. At the same time observed the CPU consumed heavily and RAM is barely used . So its seems like some memory leakage or code brake happening at web server end as we did not see any load conjunction on web server end.

So we need to dig the issue by collecting the Garbage collection data to a file. Based on the information which I’d given, There are 3 basic types data that we need to identify the a root cause of a Java application.

1. Collecting the Heap dump
This is basically pull what all the data are present in the system Memory. So this would help us to identify which function/code is currently loaded in memory.

How do I take thread dump : Execute the below command

 /var/jdk/bin/jmap  -histo $(pgrep java)   > ~/heapdump_$(date +"%Y-%m-%d_%H%M").log

The above command will pull the headp dump data to a dated separated file for future reference.

2. Collecting Thread dump
This is basically used for identify the programming side libraries/functions/forms those are being used in that particular time. This will be very useful to identify the functionality fix or brakes. So we had instructed to keep this data strictly up on any application outage.

  • How to pull the Thread dump
  •  /var/jdk/bin/jstack  -l $(pgrep java)  > ~/thread_dump_$(date +"%Y-%m-%d_%H%M").log

    Note : This command will pull the backup of all the java thread currently being executed in the memory and written it as a dated file. You also need to take these logs for a period of time to understand the history of the function loaded in memory. So I used to execute this commands 3 times in one minute interval.

    3. Verifying java application is heavily used using jstat.

    There is a utility (jstat) which collect the statistics of Garbage collection data which including the gcutils (used to check the usage of heap areas, the number of GC performed, and the total accumulated time for GC operations).

    [root@web232 ~]# /var/jdk/bin/jstat -gcutil $(pgrep java) 250 700
      S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT
      0.00  76.33 100.00 100.00  38.71    133   15.991   229 1465.177 1481.168
      0.00  76.33 100.00 100.00  38.71    133   15.991   229 1465.177 1481.168
      0.00  94.96 100.00 100.00  38.71    133   15.991   229 1466.212 1482.203
      0.00 100.00 100.00 100.00  38.71    133   15.991   230 1466.212 1482.203
      0.00 100.00 100.00 100.00  38.71    133   15.991   230 1466.212 1482.203
      0.00 100.00 100.00 100.00  38.71    133   15.991   230 1466.212 1482.203
      0.00 100.00 100.00 100.00  38.71    133   15.991   230 1466.212 1482.203
      0.00 100.00 100.00 100.00  38.71    133   15.991   230 1466.212 1482.203

    The above logs showing that Old space and Eden space was fully occupied by GC cycle. So any pending GC request will be keep in queue and web server remains running in hanging states appears even though it is working correctly. The only culprit is GC collection killing the web server and keep it forzhen. So restarting webserver will help to release the GC and hence platform bring it back quickly.

    If you see Eden space (E) and Old area (O) are showing the value 100. you application was driven in poor performance and may not be working correctly. So the options are restart the web server or kill the jave process.

    How do I kill the java process.

    /bin/kill -9 $(pgrep java)‚Äč

    Leave a Reply

    You can use these HTML tags

    <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>