SAP Basis Tech Supports

Symptom
Garbage collector (GC) details are needed for analysis of problems in the Java stack.
Other terms
Java JSE JDK JVM VM HP Hewlett Packard
Solution

Please note that mentioned “How to collect …” entries are only meant for temporary usage during problem analysis. Each of them should only be applied upon special request by Hewlett-Packard support and removed when not needed any more after problem analysis.

1. How to collect GC details for analysis by HPjmeter
2. How to collect application profiling data
3. Important parameters of java servers influencing GC

1. How to collect GC details for analysis by HPjmeter
Add
-Xverbosegc:file=<file_name>.vgc
to the java options of the server (see note 710146).
Please note, that this parameter is for temporary use only and should be removed when it is not needed any more.
This parameter creates data in a format that can be dislayed graphically using HPjmeter which is available at no costs at:
http://www.hp.com/go/java

2. How to collect application profiling data
Add
-Xeprof:file=<file_name>,time_on=sigusr2,time_slice=sigusr2
to the java options of the server (see note 710146).
Please choose a different signal in case of following message in the corresponding dev* file when starting:
eprof: ignoring signal <nn>
Please note, that this parameter is for temporary use only and should be removed when it is not needed any more.Send
kill -usr2 <pid> or
kill -s sigusr2 <pid>
to the java process to start and stop profiling during time of normal operation and during time with the problem for comparison.
Above mentioned kills should be executed as root.
There will be following messages in the corresponding dev* file, when receiving the signals:
eprof: starting profiling
eprof: terminating profiling
eprof: writing profile data to <file_name>
eprof: done.
The data collected will be written to <file_name> not until profiling has been terminated by the defined signal.
This parameter creates a very large amount of data in a format that can be analyzed using HPjmeter which is available at no costs at:
http://www.hp.com/go/java
It should not be turned on longer than necessary, and the fill level of the file system where data is written to, should be monitored.

3. Important parameters of java servers influencing GC
-Xmx-Xms-XX:PermSize
-XX:MaxPermSize-XX:NewSize
-XX:MaxNewSize-XX:NewRatio-XX:SurvivorRatio
-XX:TargetSurvivorRatio-XX:+DisableExplicitGC-XX:+UseParNewGC

Remarks
GC is usually not root cause of problems but in most cases generates high CPU load because full garbage collections became necessary as result of prior heap allocations by the application.
Absolute figures cannot be given, which load generated by GC can be tolerated but in general high percentage (approximately > 10%) of time in GC means
Less time spent executing applicationPoor response time due to GC pausesApplication heap settings may be too small
Time spend in GC should not increase over time, oscillation is normal.
The majority of GCs should be minor collections instead of major ones, which should only happen in larger intervals.

Additional Information
For details about above mentioned options, have a look at:
http://www.hp.com/products1/unix/java/infolibrary/prog_guide/hotspot.html
Examples for GC output interpretation in GC.log can be found at:
http://java.sun.com/docs/hotspot/gc1.4.2/example.html
For information about “Tuning Garbage Collection with the 1.4.2 JavaTM Virtual Machine” please have a look at:
http://java.sun.com/docs/hotspot/gc1.4.2/index.html