SAP JAVA Heap Memory Analyzer and logs for Portal 7.3
The information of this document contains how to check the logs in SAP Net weaver portal 7.3 and how to analyze the java heap memory in which we have to find the root cause of issue where and which objects are leaks suspected.
Author: Brindavan Mookaiah
Designation: SAP BASIS Consultant
Table of content
- SAP java stack log locations…………………………………………………………………………………………….
- SAP Java heap memory analyzer with Eclipse tool……………………………………………………………………
- 1) SAP java stack log locations
SAP java stack logs can be found in below directories which will help for BASIS Netweaver admin (what is happening and happened in server). There are two location where we find logs:
The first location is “/usr/sap/SID/J00/work “ .In this location you can find some of the logs are like dev_server0 , dev_jsmon dev_icm dev_bootstrap..etc.. but the dev_server0 which is important to help you what happened in the server during server crush or unable to startup the system.
The second location is “/usr/sap/SID/J00/j2ee/cluster/server0/log “. In this location the default trace will be available to help you to find the application level logs and issue. For example if the ABAP system is connected to portal using ADS connection, if the connection is not established or ADS is not working. It will help you in many ways.
There is one more tool called JVM-GUI which can be monitored in online of JVM. The jvm location directory is “/usr/sap/SID/SYS/exe/jvm/rs6000_64/sapjvm_6.1.061/sapjvm_6/bin”.
Through this tool you can monitor about VM details performance, debugging and trace flags. It will show the CPU time and memory area etc…
The option in Command, Print, DUMP and debugging are which you will be able to view system information, command processing dump heap …etc
2) SAP Java heap memory analyzer with Eclipse tool
The Memory Analyzer is an Open Source Project at Eclipse (http://www.eclipse.org/mat/)
The Memory Analyzer was developed to analyze productive heap dumps with hundreds of millions of objects. Once the heap dump is parsed, you can re-open it instantly,and get the retained size of single objects and quickly approximate the retained size of a set of objects. The Analyzer is (relatively) low on resource consumption, so you can analyze multi-GB heap dumps. SAP Memory Analyzer supports by default HPROF binary heap dump in SAP JAVA stack which can be found in the following directory
2.1 Download the memory analyzer tool in above link.
2.2 Double-click on MemoryAnalyzer.exe to start Memory Analyzer Tool
The screen will appear as follow:
2.3 click options file and then click open the file to load the “hprof” from the server which you have taken. The following screen will the overview of the “hprof” file.
In the above screen you can see how the memory has been used.
Then click the leak suspected option to check which object causing more memory (top contributed the foot prints).
In the above screen you can find the two problem suspect 2
One instance of “com.sap.sql.connect.pool.Pool” loaded by “com.sap.engine.boot.loader.ResourceMultiParentClassLoader @ 0x5a2c79c8” occupies 659,542,448 (33.12%) bytes. The memory is accumulated in one instance of “com.sap.sql.connect.pool.Pool” loaded by “com.sap.engine.boot.loader.ResourceMultiParentClassLoader @ 0x5a2c79c8”.
One instance of “oracle.jdbc.driver.T4CPreparedStatement” loaded by “com.sap.engine.boot.loader.ResourceMultiParentClassLoader @ 0x5a2c7ba8” occupies 580,921,280 (29.17%) bytes. The memory is accumulated in one instance of “byte” loaded by “<system class loader>”.
click on find option and paste the ID “0x5a2c79c8”.
You can find the class loader ” “0x5a2c79c8” into the new tab like below.
This class load memory address referring the heap used size. you can also drill down which class and where the heap memory used.
By filtering the top memory object for outgoing or incoming dependency to find the leak suspected. In here we are only able to see the DSR.ADMIN and buffer admin utilize. If you have problem without going dependency in application then you will able to find where exactly leak suspected. For example: closed method not used in java program or any issue foot prints can be highlighted where the leak suspected causing more memory used. Based on this analysis you can tune your program or resource wise.
Here we have found that “Resource multiple class loader “used some memory. The following utilized memory is from application into database level and update some data. It means that the portal system is connected to some ABAP or SRM system,through portal system they are accessing ABAP or SRM system for their business need and updating some data into the database.
For more details about this Memory analyzer tool visit the below link: