Monitoring and Management 
There are different tools you can use for monitoring and administration purposes. See section Tools for an overview about the tools..
Procedure
Monitoring the GC
Within the NetWeaver AS Java one can briefly get an overview of the servers’ current GC behavior via the SAP Management Console (SAP MMC). For a more detailed analysis we recommend to turn on the GC statistic trace level 6 via jvmmon. You can also dump the GC history with this tool when for example an interesting GC just occurred.
SAP MMC GC History
The SAP MMC has a history of the 20 recent GCs and in addition the last 20 GCs, which collects the old generation. It contains the following information:
The process where the GC occurred (e.g. server0)
The type of GC
Small GC means young generation garbage collection
Full GC means young and old generation garbage collection
Concurrent GC means the mostly concurrent old generation garbage collection
The reason for a GC
Allocation failure means the remaining free space in eden is less than the requested objects size). This is a normal reason for a GC.
Old generation low on memory
Explicit: someone requested a GC (e.g. System.gc() or with jvmmon)
The start time of the GC
In case of a concurrent GC this is in fact the end time.
The duration is the Stop-The-World time – also for the concurrent GC where the application is stopped
The page faults are the sum of major and minor page faults. The GC statistic trace distinguishes the major and minor page faults.
NoteA major page fault causes the operating system needs to read a page from the page file
In case of minor page fault the page is swapped out but still on the free list or it can be caused by a TLB (translation lookaside buffer) miss
Currently on Windows Operating Systems we cannot distinguish between major and minor.
End of the note.The CPU time of all GC threads for the whole cycle. In case of the concurrent GC this includes also the CPU time spent in the concurrent part
The objects in the heap before and after the GC. In case of the concurrent GC both contain the fill level of the old generation after the GC.
The objects being freed In case of concurrent GC this will always be 0 KB.
The classes (perm usage) before and after the GC. In case of the concurrent GC both contain the fill level of the old generation after the GC.
The heap column is only shown due to backward compatibility reasons.
(Screenshot of the GC History in SAP MMC)
SAP JVM GC Statistic
A garbage collection statistic is automatically printed by the SAP JVM whenever a GC has taken more than 60 seconds. This GC statistic contains a main section, which describes the long running GC, followed by several sections for each GC event. Within the NetWeaver AS Java, you will find this trace output in dev_server0 and std_server0.out in the work directory (/usr/sap/<SID>/<inst_no>/work).
Does my Server Have a GC Issue?
If application performance is not satisfying and a garbage collection issue is suspected, look for GC statistic records in the trace files and read the GC History information in SAP MMC. There are different kinds of possible garbage collection issues. GC runs might take a very long time to finish, or full GCs occur very frequently.
Frequent Full GCs
(Example of the GC History Display with Full Old Generation)The GC cannot free enough memory in the old generation. It is triggered frequently. Solutions: increase the old generation, fix a memory leak, reduce the load of the server or increase the number server nodes.
Long Running GCs
If the GC duration is much more than the CPU time consumption, either the server (the hardware box) is under high load and no more CPU resources are available or the OS needs to page in parts of the heap (check the page faults column or search the dev_server<N> or std_server<N> trace files for “suspicious long running GC”).