SAP JAVA Heap Memory Analyzer and logs for Portal 7.3
Summary:-
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
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
“/usr/sap/SID/J00/j2ee/cluster/server0 “000.hprof.
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 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>”.
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.
For more details about this Memory analyzer tool visit the below link:
http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/40244428-5703-2a10-17af-9e878922f900?QuickLink=index&…
source: scn.sap.com
Summary:-
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
“/usr/sap/SID/J00/j2ee/cluster/server0 “000.hprof.
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).
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.
http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/40244428-5703-2a10-17af-9e878922f900?QuickLink=index&…
source: scn.sap.com
Comments
Post a Comment