I have got some Load Testing / Stress testing issues in my J2EE application.
I am using JVisualVm for detecting any memory leaks in one of the modules.
The following are the steps i used to detect memory leaks. Please correct me if i am not doing it correct.
Step 1 : Initialize Weblogic Server run the Web application
Step 2: Initialize JVisualVM and start Memory Profiliing.
Step 3 : Perform some operations in the related module.
Step 4 : Now take a snapshot of the Memory.
Step 5 : Move on to another module which has completly different Packages or referred classes
Step 6 : Perform some operation and repeat Step 4.
Step 7 : Compare both the snapshots and see if any objects related to first Modules are remaining in the second Snapshot.
Step 8 : If there are no objects / their allocations then there is no memory leak.
Are these steps correct ?
Now if i found a memory leak then how to trace which method in that class or which object in that class is creating the issue?
Chris Hurst wrote:I'd start with enabling gc logs , then use gcviewer to try and understand what your gc activity is like and is it getting worse with time. The next tool I use is Eclipse MAT and its reports eg top consumer, memory leak suspects, after that I usually know if I have an issue and then employ Visual VM if I need to drill down.
Yeah, GC is a good tool too. Check the time spend on GC is less than 10% of time , for example.
Think of looking at a heap dump like being a detective at a crime scene. Let's say a guy is shot, and you are the detective. By looking at the crime scene, you can see exactly how the guy died, but you can't tell who did it. To find out who did it, you need to collect other pieces of information and put them together to find exactly what happened. Now, it would be very convenient if there was a camera recording the crime when it happened. You can go to the recording and see what happened. Boom. you have your culprit. But, when you don;t have a camera recording, that's whn you have to use your detective skills. You have to talk to people, and try to make a picture of what happened before the shooting.
ANalyzing a memory leak is just like that. By looking a heap dump, you can tell what exactly caused the heap to fill up. It won;t tell you how it happneed. Now, if you had detailed enough logs, then that would be like a camera pointed at the crime scene. You could go through the logs and find exactly where those objects that filled up the heap got created. Not as easy as watching a recording, but doable. If you don't have logs, then you need to piece together other information to find what happened. you should look at the pattern used to reproduce the problem, and look at the source code to find where the object is being created.
Fortunately, for us software engineers, finding how to reproduce a problem is like going back in time. If you can reproduce the problem consistently, and you have a good idea of which object is causing the problem, you can add logging and the reproduce the problem again. That's like going back in time, putting a camera on the crime scene and letting the crime happen.