Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Archived » Memory Analyzer (MAT) » Help understanding Heap Analysis
Help understanding Heap Analysis [message #5464] Thu, 16 October 2008 16:38 Go to next message
Nirmal Kumar is currently offline Nirmal Kumar
Messages: 8
Registered: July 2009
Junior Member
Hi everybody,

I'm testing a web application(Struts 2.0, Spring 2.0, Hibernate 3.0, JDK
1.5.0_15, Tomcat 5) which has some potential memory related problems.

Initially the application was giving "java.lang.OutOfMemoryError: PermGen
space".
The PermGen settings were default i.e. Min:16M & Max:64M

I tried and load test the application with JMeter and again reproduced the
same "java.lang.OutOfMemoryError: PermGen space".

After that I changed the PermGen settings to Min:32M & Max:256M
After this there were no "java.lang.OutOfMemoryError: PermGen space"
issues..

Next I chose "Eclipse Memory Analyzer" to analyze the Heap dumps.
I also heard of "Leaking ClassLoaders". I tried identifying those too but
didnt succeed may be I am new to "Eclipse Memory Analyzer".

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.

This way I guess I'll be able to identify the potential memory leaks in
the application....

IS MY STRATEGY CORRECT?
IS THERE ANY OTHER WAY OF SOLVING THE POTENTIAL MEMORY RELATED PROBLEMS IN
MY APPLICATION?

Please give some suggestions or alternatives as I'm new in using Eclipse
Memory Analyzer.

Thanks & Regards,
Nirmal
Re: Help understanding Heap Analysis [message #5470 is a reply to message #5464] Thu, 16 October 2008 18:13 Go to previous messageGo to next message
Claudio Miranda is currently offline Claudio Miranda
Messages: 6
Registered: July 2009
Junior Member
> (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>

I strongly suggest you to use JDK 6 (latest update), as "jmap -dump" uses
a different algorithm (HeapDumper) to generate dumps, more reliable than
jmap -heap:format=b, in some circumstances.
Re: Help understanding Heap Analysis [message #5476 is a reply to message #5470] Fri, 17 October 2008 04:31 Go to previous messageGo to next message
Nirmal Kumar is currently offline Nirmal Kumar
Messages: 8
Registered: July 2009
Junior Member
Hi,
Thanks a lot for the response.
I know that jmap on jdk 1.6 using the following command generates the
correct heap dump:
jmap -dump:format=b,file=HeapDump.hprof 3312
Here in this case we can specify the file too.So i get the heap dump in
"HeapDump.hprof" file in the current directory.
This file gets opened in SAP Memory Analyzer and thereafter I can start
our analysis.
But the problem is that I have to use JDK 1.5 only.... as there is some
major concerns regarding that.
Initially I was using :SAP Memory Analyzer". I am using jmap in jdk
1.5.0_15 using the following command:
jmap -heap:format=b 26915

The problem with jmap in jdk 1.5.0_15 is that it always generates the heap
as a binary format with .bin extension(heap.bin)
And this heap dump taken with jmap in jdk 1.5.0_15 cannot be open or
analyzed with any of the tools like SAP Memory Analyzer.
That is why I finally moved to "Eclipse Memory Analyzer" which can open
Heap dumps taken from jmap in jdk 1.5.

Please give some advice in how should I go for the Heap Analysis with my
application.

Thanks & Regards
Nirmal
Re: Help understanding Heap Analysis [message #5485 is a reply to message #5464] Fri, 17 October 2008 07:59 Go to previous messageGo to next message
Krum Tsvetkov is currently offline Krum Tsvetkov
Messages: 149
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 Go to previous messageGo to next message
Nirmal Kumar is currently offline 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 #5501 is a reply to message #5495] Fri, 17 October 2008 10:29 Go to previous messageGo to next message
Krum Tsvetkov is currently offline Krum Tsvetkov
Messages: 149
Registered: July 2009
Senior Member
> Is that mean that I can't identify whether my application has some
> "Leaking Classloaders" or not using "Eclipse Memory Analyzer" ? ? ?

If you have an application deployed on the SAP server, you can try to stop
/ start the app, or may be redeploy the app. Then take a heap dump and run
the Leaking Loaders query. If the classloader for the stopped / redeployed
app is not reclaimed, you shoulld be able to see it.

Does this answer the question?
Re: Help understanding Heap Analysis [message #5507 is a reply to message #5476] Fri, 17 October 2008 14:40 Go to previous messageGo to next message
Elena Nayashkova is currently offline Elena Nayashkova
Messages: 12
Registered: July 2009
Junior Member
> The problem with jmap in jdk 1.5.0_15 is that it always generates the heap
> as a binary format with .bin extension(heap.bin)
> And this heap dump taken with jmap in jdk 1.5.0_15 cannot be open or
> analyzed with any of the tools like SAP Memory Analyzer.
> That is why I finally moved to "Eclipse Memory Analyzer" which can open
> Heap dumps taken from jmap in jdk 1.5.

In fact, you are talking about one tool. The name "SAP Memory Analyzer"
was changed to "Eclipse Memory Analyzer" when the tool was contributed to
the Eclipse open source community. The feature allowing to open the heap
dumps, depending on their content, not extension, was added several months
ago.
Re: Help understanding Heap Analysis [message #5680 is a reply to message #5485] Sat, 18 October 2008 10:43 Go to previous messageGo to next message
Nirmal Kumar is currently offline 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
Re: Help understanding Heap Analysis [message #5698 is a reply to message #5470] Sun, 19 October 2008 08:33 Go to previous messageGo to next message
Nirmal Kumar is currently offline Nirmal Kumar
Messages: 8
Registered: July 2009
Junior Member
Claudio Miranda wrote:

>> (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>

> I strongly suggest you to use JDK 6 (latest update), as "jmap -dump" uses
> a different algorithm (HeapDumper) to generate dumps, more reliable than
> jmap -heap:format=b, in some circumstances.

Hi,

Thanks for teling that but the problem is that I have to use JDK 1.5
only.... as there is some major concerns regarding that.

That's why I am using :
jmap -heap:format=b <pid> (#For jdk 1.5.0_15)
instead of
jmap-dump:format=b,file=HeapDump.hprof 26915 (#For jdk 1.6..)

Thanks & Regards
Nirmal
Re: Help understanding Heap Analysis [message #5734 is a reply to message #5680] Tue, 21 October 2008 09:43 Go to previous messageGo to next message
Krum Tsvetkov is currently offline Krum Tsvetkov
Messages: 149
Registered: July 2009
Senior Member
Hi,

May be the result show that there is no memory problem within the tree
applications? Or you are confident that there is one?

You can send me the reports at my_first_name dot my_last_name at sap dot
com

krum tsvetkov
Re: Help understanding Heap Analysis [message #5752 is a reply to message #5734] Tue, 21 October 2008 12:37 Go to previous messageGo to next message
Nirmal Kumar is currently offline Nirmal Kumar
Messages: 8
Registered: July 2009
Junior Member
Hi,

I think there are definitely some major memory related problems in the
application as we have encountered them in the past itself.

I'll send you my heap analysis report so that you can put some light on
the actual problem creaters.

One thing more I want to ask is that as all the interned String objects
are stored in the Permanent Generation space.
If some application has a large number of interned Strings then that might
soon be a victim of OutOfMemory:Permgen space.

Is there any tool in JDK1.5(beside jconsole) or MAT tool that can show me
all the interned Strings ?

Another question or doubt:
**Does calling session.invalidate() also removes all the session
attributes?**
Like our application stores an ArrayList(containing String objects)in the
session as soon as the User logs in.
When the user logs off we call session.invalidate().
Does calling session.invalidate() will actually remove the ArrayList from
the heap?
or
We have to manually remove all the session attributes that we have set.

Thanks & Regards,
Nirmal
Re: Help understanding Heap Analysis [message #5769 is a reply to message #5752] Tue, 21 October 2008 14:09 Go to previous messageGo to next message
Krum Tsvetkov is currently offline Krum Tsvetkov
Messages: 149
Registered: July 2009
Senior Member
> I think there are definitely some major memory related problems in the
> application as we have encountered them in the past itself.

If the problems didn't appear during the test, you can consider to have
the -XX:+HeapDumpOnOutOfMemoryError option for the VM always set. It does
not have any runtime overhead, and will ensure that if the system gets
into an OutOfMemoryError there will be a proper .hprof dump.

> One thing more I want to ask is that as all the interned String objects
> are stored in the Permanent Generation space.
> If some application has a large number of interned Strings then that might
> soon be a victim of OutOfMemory:Permgen space.
> Is there any tool in JDK1.5(beside jconsole) or MAT tool that can show me
> all the interned Strings ?

Unfortunately I don't know any tool which is able to show you this info.
So, may be there is one, but I don't know about it.


> Another question or doubt:
> **Does calling session.invalidate() also removes all the session
> attributes?**
> Like our application stores an ArrayList(containing String objects)in the
> session as soon as the User logs in.
> When the user logs off we call session.invalidate().
> Does calling session.invalidate() will actually remove the ArrayList from
> the heap?
> or
> We have to manually remove all the session attributes that we have set.

What happens on calling session.invalidate() depends on the implementation
of the web container you are using. I can't give you an answer here. I can
only that suppose an app server will remove all the references it keeps to
the java object representing the session. If this object is then not
referenced by any other object, it could be GC-ed. If the arguments are
only referenced through the sessions - they should be also GC-ed. But as I
said, this is only what I suppose. You may have a look with in the heap
dumps, if you know which java objects represent the http session.

regards,
krum
Re: Help understanding Heap Analysis [message #5802 is a reply to message #5769] Tue, 21 October 2008 16:00 Go to previous messageGo to next message
Nirmal Kumar is currently offline Nirmal Kumar
Messages: 8
Registered: July 2009
Junior Member
Krum Tsvetkov wrote:

>> I think there are definitely some major memory related problems in the
>> application as we have encountered them in the past itself.

> If the problems didn't appear during the test, you can consider to have
> the -XX:+HeapDumpOnOutOfMemoryError option for the VM always set. It does
> not have any runtime overhead, and will ensure that if the system gets
> into an OutOfMemoryError there will be a proper .hprof dump.

Thats correctly said we've already set -XX:+HeapDumpOnOutOfMemoryError
option set as it does not have any runtime overhead

>> One thing more I want to ask is that as all the interned String objects
>> are stored in the Permanent Generation space.
>> If some application has a large number of interned Strings then that might
>> soon be a victim of OutOfMemory:Permgen space.
>> Is there any tool in JDK1.5(beside jconsole) or MAT tool that can show me
>> all the interned Strings ?

> Unfortunately I don't know any tool which is able to show you this info.
> So, may be there is one, but I don't know about it.

Well I'm investigating on this and as soon I find something I'll intimate
you.

>> Another question or doubt:
>> **Does calling session.invalidate() also removes all the session
>> attributes?**
>> Like our application stores an ArrayList(containing String objects)in the
>> session as soon as the User logs in.
>> When the user logs off we call session.invalidate().
>> Does calling session.invalidate() will actually remove the ArrayList from
>> the heap?
>> or
>> We have to manually remove all the session attributes that we have set.

> What happens on calling session.invalidate() depends on the implementation
> of the web container you are using. I can't give you an answer here. I can
> only that suppose an app server will remove all the references it keeps to
> the java object representing the session. If this object is then not
> referenced by any other object, it could be GC-ed. If the arguments are
> only referenced through the sessions - they should be also GC-ed. But as I
> said, this is only what I suppose. You may have a look with in the heap
> dumps, if you know which java objects represent the http session.

This thing I'm getting cleared here:
http://forums.sun.com/thread.jspa?messageID=10474415

Thanks & Regards
Nirmal
Re: Help understanding Heap Analysis [message #6338 is a reply to message #5802] Thu, 30 October 2008 07:56 Go to previous message
Taras Tielkes is currently offline Taras Tielkes
Messages: 38
Registered: July 2009
Member
If you're seeing objects in the dump which "shouldn't" be there, look up
their path(s) to GC root(s).

That should quickly answer the question why they're not being GCed.

-tt
Previous Topic:Saving content of char[]/byte[]/String/StringBuffer to file
Next Topic:JVM Terminates immediately under Mac OS X w/ J2SE 6.0
Goto Forum:
  


Current Time: Sat Oct 25 03:38:53 GMT 2014

Powered by FUDForum. Page generated in 0.02086 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software