Home » Archived » Memory Analyzer (MAT) » Help understanding Heap Analysis
| | |
| Re: Help understanding Heap Analysis [message #5485 is a reply to message #5464] |
Fri, 17 October 2008 07:59   |
 Krum Tsvetkov
Messages: 165
Registered: July 2009 |
Senior Member |
|
|
Hi,
> I also heard of "Leaking ClassLoaders". I tried identifying those too but
> didnt succeed may be I am new to "Eclipse Memory Analyzer".
The "Leaking Classloaders" is part of the SAP NetWeaver extensions for MAT
and recognizes left-over classloaders in heap dumps from the SAP
application server only. Recently I blogged about it at the SAP Developers
Network site: https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/11129
> The strategy that I'm thinking goes like this:
> (1). First I will identify some important/potential use cases that might
> consume more memory(say 30-50 use cases)
> (2). Next after performing that use case in the application I will be
> taking the Heap Dump using jmap using:
> jmap -heap:format=b <pid>
> (3). For each of the identified use cases I'll be analyzing the Heap Dump
> and accordingly collecting statistics.
What Memory Analyzer is very good at - it shows you where most of the
memory is kept - the biggest objects, classes, etc...
If you have a memory leak and there is enough space for it to occupy, then
it will be very easy to see it with MAT. As example - assume you have an
application which normaly runs with 500 - 700 mb (after full GC). If you
give the VM -Xmx800m, you will probably not be able to see the problem
once it occurs. But if you give the VM 1500Mb, then the leak will "eat"
about 700-800 Mb before the system goes into OutOfMemoryError, and you can
see the big problem at a glance with MAT afterwards.
However, what you want to do is different (as far as I understood). You
want to proactively search for leaks, without waiting for them to grow too
much. And this will be difficult to analyze with only one snapshot.
What you could do for every scenario is:
1) warm the system up - run the whole scenario once, so that all necessary
caches get filled, all needed initialization is done. Take a heap dump then
2) without restarting, execute the same scenario again. At the end take
another heap dump.
If the warm up was proper, then I expect that at the end of the second
test the heap should be at the same level as at the end of the first test.
You can just compare both dumps. Unfortunately, for now we offer a very
limited compare functionality - only on class histogram level. I recommend
you that you compare the dominator tree, grouped by class or package. You
can export the data from both dumps and compare (not within the tool).
Thus you should be able to see if some classes / packages got bigger after
the second test.
What do you think about the suggestion? I'd be happy to hear from you,
when you finish with the tests, if this helped with the analysis or not.
Regards,
Krum
|
|
|
| Re: Help understanding Heap Analysis [message #5495 is a reply to message #5485] |
Fri, 17 October 2008 09:33 |
Nirmal Kumar
Messages: 8
Registered: July 2009 |
Junior Member |
|
|
Hi,
First of all thanks a lot for showing me the right direction.
As you wrote:
The "Leaking Classloaders" is part of the SAP NetWeaver extensions for
MAT and recognizes left-over classloaders in heap dumps from the SAP
application server only. Recently I blogged about it at the SAP Developers
Network site: https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/11129
Is that mean that I can't identify whether my application has some
"Leaking Classloaders" or not using "Eclipse Memory Analyzer" ? ? ?
I'm asking this thing beacuse earlier our application was giving
"java.lang.OutOfMemory : PermGen space" error.
Well, I'll follow your guidelines:
1) warm the system up - run the whole scenario once, so that all necessary
caches get filled, all needed initialization is done. Take a heap dump then
2) without restarting, execute the same scenario again. At the end take
another heap dump. If the warm up was proper, then I expect that at the
end of the second test the heap should be at the same level as at the end
of the first test. You can just compare both dumps. Unfortunately, for now
we offer a very limited compare functionality - only on class histogram
level. I recommend you that you compare the dominator tree, grouped by
class or package. You can export the data from both dumps and compare (not
within the tool).
Thus you should be able to see if some classes / packages got bigger after
the second test.
I am sure I'll come up with good results.
Thanks & Regards,
Nirmal
|
|
| | |
| Re: Help understanding Heap Analysis [message #5680 is a reply to message #5485] |
Sat, 18 October 2008 10:43 |
Nirmal Kumar
Messages: 8
Registered: July 2009 |
Junior Member |
|
|
Krum Tsvetkov wrote:
> Hi,
>> I also heard of "Leaking ClassLoaders". I tried identifying those too but
>> didnt succeed may be I am new to "Eclipse Memory Analyzer".
> The "Leaking Classloaders" is part of the SAP NetWeaver extensions for MAT
> and recognizes left-over classloaders in heap dumps from the SAP
> application server only. Recently I blogged about it at the SAP Developers
> Network site: https://www.sdn.sap.com/irj/sdn/weblogs?blog=/pub/wlg/11129
>> The strategy that I'm thinking goes like this:
>> (1). First I will identify some important/potential use cases that might
>> consume more memory(say 30-50 use cases)
>> (2). Next after performing that use case in the application I will be
>> taking the Heap Dump using jmap using:
>> jmap -heap:format=b <pid>
>> (3). For each of the identified use cases I'll be analyzing the Heap Dump
>> and accordingly collecting statistics.
> What Memory Analyzer is very good at - it shows you where most of the
> memory is kept - the biggest objects, classes, etc...
> If you have a memory leak and there is enough space for it to occupy, then
> it will be very easy to see it with MAT. As example - assume you have an
> application which normaly runs with 500 - 700 mb (after full GC). If you
> give the VM -Xmx800m, you will probably not be able to see the problem
> once it occurs. But if you give the VM 1500Mb, then the leak will "eat"
> about 700-800 Mb before the system goes into OutOfMemoryError, and you can
> see the big problem at a glance with MAT afterwards.
> However, what you want to do is different (as far as I understood). You
> want to proactively search for leaks, without waiting for them to grow too
> much. And this will be difficult to analyze with only one snapshot.
> What you could do for every scenario is:
> 1) warm the system up - run the whole scenario once, so that all necessary
> caches get filled, all needed initialization is done. Take a heap dump then
> 2) without restarting, execute the same scenario again. At the end take
> another heap dump.
> If the warm up was proper, then I expect that at the end of the second
> test the heap should be at the same level as at the end of the first test.
> You can just compare both dumps. Unfortunately, for now we offer a very
> limited compare functionality - only on class histogram level. I recommend
> you that you compare the dominator tree, grouped by class or package. You
> can export the data from both dumps and compare (not within the tool).
> Thus you should be able to see if some classes / packages got bigger after
> the second test.
> What do you think about the suggestion? I'd be happy to hear from you,
> when you finish with the tests, if this helped with the analysis or not.
> Regards,
> Krum
Hi Krum,
I am using JMeter. I recorded a long conversation covering almost every
operation in the application. Then I ran that conversation with 50
concurrent users in JMeter thus creating a good load on the server.
At the completion of this conversation of 50 users I took the Heap
dump(named it "firstHeap50Users").
Next I stoppped all the threads for 50 users in the JMeter and again
followed the same procedure i.e ran the conversation with 50 concurrent
users in JMeter.
Again took the heap dump named it "secondHeap50Users".
This process I repeated 4 times and hence I am having 4 dumps:
1.)"firstHeap50Users" 64.7 MB
2.)"secondHeap50Users" 101 MB
3.)"thirdHeap50Users" 96.1 MB
4.)"fourthHeap50Users" 111 MB
I then analyzed the 4 heap dumps but didnt find any success as everytime
the reports are similar and there is'nt any case like you said to find:
> Thus you should be able to see if some classes / packages got bigger after
> the second test.
Actually my web application uses 2 more applications i.e on the single
instance of Tomcat there are 3 web applications running at a time.
Tomcat has the following web apps running:
1.crystal
2.crystal_mny
3.pretups(This is my web application that use the first two web apps)
Hence here are 3 "WebappClassLoader(one for each web application)" shown
in the Heap Analysis Report.
I have even collected reports separately for the 4 heap dumps in an excel
file.
I can send you that so that you can help me out where exactly I should
analyze.....
Thanks & Regards
Nirmal
|
|
| | | | | | |
Goto Forum:
Current Time: Thu Dec 12 16:43:48 GMT 2024
Powered by FUDForum. Page generated in 0.05504 seconds |