Performance Problems - Shared Garbage Collector Running Too Often 

Problem Description

The shared pool is a global memory area in the VM Container that is used by all Java VMs for shared Java classes and for shared Java objects (shared closures). No later than once 90% of this global memory becomes occupied, a shared garbage collector (SGC) removes objects that are no longer referenced, and frees up the memory space they were occupying. If the SGC cannot free up any memory, or can only free up a small amount of memory, this means the size of the shared pool is set too small. In this case, further attempts to free up memory by starting the SGC again will not work. Since an SGC uses CPU time and is therefore expensive, if it is running too often it can lead to system performance problems. These can be prevented by increasing the size of the pool.

Scenario Type:	Configuration Analysis
NetWeaver Component:	VM Container
Validity:	7.00

Decision Roadmap

Prerequisites

The shared pool is created only when the VM Container is activated on this instance. The VM Container can be activated as described in note 854170.

Main Tools

SM52, SM53

Analysis

After the system has been started, or if the workload is small, initially there may be sufficient free memory even if the shared pool is set too small. You can only tell whether the size of the shared pool is large enough, once the workload becomes heavy. For this reason we recommend that you monitor the memory utilization of the pool size over a certain time period.

You can use transaction SM52 to monitor the shared pool and the SGC. In SM52 you can, for instance, display the total memory currently used in the shared pool, the state of the shared GC and the SGC state of the VMs. The graphic below is a screen-shot taken from transaction SM52 and shows these three parameters circled in red.

The maximum size of the shared pool can be set in the profile parameter vmcj/option/ps. The graphic above shows the SGC in escalation mode (SGC is compelled to contribute). In the escalation mode the shared GC has the state, “Active; VMs have to contribute”. This must not be confused with the non-critical state, “Active; VMs should contribute”. The escalation mode becomes active as soon as 90% of the shared pool is filled. The SGC then categorically attempts to free up memory and compels all VMs to contribute to this process. This costs CPU time and can result in performance problems if the SGC is running too often.  In the worst case scenario it could even be running permanently. If it is, this means that the pool size is so small that 90% of it is needed by objects being currently referenced. This means the SGC can no longer free up enough memory and one SGC after another is started in escalation mode. This bad-case scenario can be easily identified in transaction SM52 (see graphic above). The size of the shared pool must definitely be increased. The rule of thumb is: After an SGC has been started, the size of the shared pool should be considerably lower than 90%.

In transaction SM53 you can manually compel an SGC to contribute. In this way you can check how much memory in the shared pool is actually being used at this moment. As you can see in the graphic below, to compel an SGC to contribute choose Shared Closures in the Navigation menu to get to the baggage cart icon, circled in red.

If the SGC is not in the "inactive” state, it has to be started twice so that the full amount of memory no longer needed can be freed up. As a precaution we recommend you start the SGC twice anyway. The rule of thumb is: After one, or rather two, SGCs have been started, the size of the shared pool should be considerably lower than 90%.

Additional Information

General VM Container documentation: SAP Virtual Machine Container

VMC architecture including resource and memory management: Architecture of the VM Container

Administration (SM52, SM53): Administration of the VM Container

VMC operation. Operation of the VM Container