killing the memory eaters

[Former Member]

I have uploaded the heap dump throug memory analyzer and found the memory eater through

the below steps.

1. Go to the Dominator tree view and from there I went to

2. "Paths from the GC Roots" ...> "without weak and soft references"

Now I am able to view the references with the names of the fields.

So now I am able to view the memory eaters. For example the below one

com.sap.engine.boot.CoreClassLoader @ 0x9ffffffef3709dd0" occupy 57,651,976 (15.71%) bytes

But how can I kill those memory eaters ?? We are working on SAP PI 7.0. Please advise.

thanks

kumar

[elena_nayashkova · Accepted solution]

Hi Kumar,

try to run the Leak Hunter query first. If will return you an HTML report with the description of the memory leak suspects.

Best Regards,

Elena.

[Former Member · Accepted solution]

HI Elena

When I ran "Leak Hunter" query I have got this message.

**********************************************************************************************

234 instances of "com.sap.engine.core.service630.container.ComponentClassLoader", loaded by "com.sap.engine.boot.CoreClassLoader @ 0x9ffffffef3709dd0" occupy 57,651,976 (15.71%) bytes.

Biggest instances:

com.sap.engine.core.service630.container.ComponentClassLoader @ 0x9ffffffef3de0260 - 19,909,104 (5.42%) bytes.

com.sap.engine.core.service630.container.ComponentClassLoader @ 0x9ffffffef3de3720 - 16,997,160 (4.63%) bytes.

com.sap.engine.core.service630.container.ComponentClassLoader @ 0x9ffffffef3de2330 - 4,113,176 (1.12%) bytes.

Keywords

com.sap.engine.core.service630.container.ComponentClassLoader

com.sap.engine.boot.CoreClassLoader @ 0x9ffffffef3709dd0

*********************************************************************************************

If this is a problem suspect, how can I rectify the problem. If I am not wrong these are at system level

API's and nothing I can do to fix this. Please correct me.

Thanks

kumar

[krumts · Accepted solution]

Hi Kumar,

The Leak Hunter report does analysis for the single objects (or objects of one class) which occupy more than 15% of the total heap. In your case the class you see is the class of the classloader used to load different applications, services, etc...

I don't think this shows any problem so far.

Further more, looking at the sizes - 57Mb == 15% - means that the total heap is about 400Mb. And this total heap is something pretty normal.

So, let me ask - was the heap dump you are analysing taken because of a problem (OutOfMemoryError or too high memory consumption at that time), or was it taken during a normal run of the server?

Regards,

Krum

[Former Member · Accepted solution]

Hi Krum,

Appreciate your elaborate and correct guess of the situation !

Yes ! It was taken during the normal run of the server. Just want to bench mark our server so that during abnormal working condition's we can identify the problem. Below are biggest Objects. We have 350.1MB as heap. And memory consumed by these biggest objects is 148.2 MB. So free heap memory left is 201.9 MB. Below are the object names. In this regard we have few queries ?

1. How can we know what are all these objects and what they do ??

2. Is there any literature so that we can know what these objects exactly do ??

3. How can we know howmuch percentage of heap these objects should consume in healthy condition ??

4. Suppose if these objects consumes more heap, how to fix that problem ?? e. class loader used to load different applications, services, etc consumes more memory etc., In this case how to solve the problem ?? Is there any literature which can explain possible problem and the corresponding solutions ??

****************************************Biggest Objects****************************************************

1. com.sap.engine.core.service630.container.ComponentClassLoader @ 0x9ffffffef3de0260

2. com.sap.engine.core.service630.container.ComponentClassLoader @ 0x9ffffffef3de3720

3. com.wily.util.ConfigurationWatcher @ 0x9ffffffef3758680

4. com.sap.aii.ib.server.util.ClusterSyncedCache @ 0x9ffffffeffc41c90

5. com.sap.pj.jmx.server.MBeanServerImpl @ 0x9ffffffef5270b08

6. com.sap.sql.jdbc.direct.DirectPreparedStatement @ 0x9fffffff050da150

7. com.sap.engine.boot.FrameClassLoader @ 0x9ffffffef3702a20

8. java.lang.ref.Finalizer @ 0x9fffffff0d07d6d8

9. com.sap.engine.core.thread.impl3.ActionObjectPool @ 0x9ffffffef3719ba0

10.com.sap.aii.af.service.cpa.impl.cache.CacheManager @ 0x9ffffffef6a9cdb0

11.class com.sap.engine.services.jndi.persistentimpl.memory.JNDIMemoryImpl @ 0x9fffffff615ec058

12.com.sap.engine.library.monitor.mapping.ccms.CcmsConnector @ 0x9ffffffef6821488

13.com.sap.sldserv.DataCollector @ 0x9ffffffef68245a8

14.com.sap.engine.core.service630.container.ComponentClassLoader @ 0x9ffffffef3de2330

15.com.sap.engine.services.deploy.server.ApplicationLoader @ 0x9ffffffef8fcf628

***********************************************************************************************************

Thanks

kumar

[krumts · Accepted solution]

> 1. How can we know what are all these objects and what they do ??

What they do you wan't be able to see. But you can get more information about the classloaders if you have the NetWeaverExtensions installed - see [https://wiki.sdn.sap.com/wiki/display/Java/DownloadtheSAPNetweaverenhancementsfortheEclipseMemoryAnalyzer|https://wiki.sdn.sap.com/wiki/display/Java/DownloadtheSAPNetweaverenhancementsfortheEclipseMemoryAnalyzer]

Then for most of the classloaders you should see names - the names of services, applications, libraries.

> 2. Is there any literature so that we can know what these objects exactly do ??

Can't answer. These are all components running on the server. I guess reading general help may throw some light.

> 3. How can we know howmuch percentage of heap these objects should consume in healthy condition ??

The sizes depend on the way the system is used. The memory used by the EJB container for example will grow with the number of EJBs deployed. The same applies for web container, WebDynpro, etc... I think whay one could do is measure the concrete system/landscape. Observe the GC behaviour (not with MemoryAnalyzer) of the normal system, or take some heap dumps after the system has been used for some time, so that it is in a "warm" state. And then look at the heap dumps to see the consumption.

> 4. Suppose if these objects consumes more heap, how to fix that problem ?? e. class loader used to load different applications, services, etc consumes more memory etc., In this case how to solve the problem ?? Is there any literature which can explain possible problem and the corresponding solutions ??

If there is for example a memory leak, then sooner or later the system will run into an OutOfMemoryError. You can then analyze the produced heap dumps and see where the memory is kept. If it is within an SAP component, then you can use the normal SAP support channels - SAP notes, OSS messages, etc...

If it is in custom coding, then you can use the hints provided by the Memory Analyzer to see where exactly memory is kept and try to fix the problem.

I don't know any universal algorithm for solving problems with memory consumption in general.