Monitoring and Management

Monitoring the GC

Within SAP NetWeaver AS Java, you can get an overview of the servers' current GC behavior using the SAP Management Console (SAP MMC). For a more detailed analysis we recommend you turn on the GC statistic trace level 6 using jvmmon. You can also dump the GC history with this tool, if, for example, an interesting GC has just occurred.

SAP MMC GC History

The SAP MMC keeps a history of the 20 most recent GCs, and in addition the last 20 GCs that collect 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.

  Note

  • A major page fault causes the operating system ? to read a page from the page file

  • In the case of a minor page fault the page is swapped but is still on the free list, or the fault can be caused by a TLB (translation look aside buffer) miss

  • Currently on Windows Operating Systems we cannot distinguish between major and minor faults.

• The CPU time of all GC threads for the whole cycle. In the case of a concurrent GC this also includes the CPU time spent in the concurrent part

• The objects in the heap before and after the GC. In the case of a concurrent GC both contain the fill level of the old generation after the GC.

• The objects being freed. In the case of a concurrent GC will always be 0 KB.

• The classes (perm usage) before and after the GC. In the case of a 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.

For more information on GC history options, see Configuration and Setup of SAP JVM - Configuring GC History .

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 SAP 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 satisfactory 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

  

  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” ).