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
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
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).
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.