Monitoring the VM Container 

Use

The monitoring functions described below will help you to ascertain whether the VM Container is functioning properly and whether the applications based on it are functioning too.  Simple ways to analyze the workload in the VM Container are also described. In principal an application sever can become overloaded because too many single tasks are being executed simultaneously or because the tasks are taking too long (or both).

Snapshot analyses can be used to show how the system is currently doing.Logs and statistics can be used for a retrospective analysis of the system.

This documentation is restricted to issues for applications that use the VM Container.

Features

Check Functioning of the VM Container

You can use report RSVMCRT_HEALTH_CHECK to check whether the VM Container is activated and functioning. This check should result in green traffic lights only.If the VM Container is not activated or it has been deactivated, this is indicated by a grey light (see Management of the VM Container, section Staring and Stopping). If some of the lights are reds there is an error and this should notified to SAP.

Check VMs

The VM Container provides virtual machines (Java VMs) to execute Java code, and if required these are integrated into a work process. An overview of the available VMs as well as the memory areas used by them in the shared memory can be seen in the VM Overview (transaction SM52).For the VM Container to function correctly the following conditions apply:

●     There should always be enough VMs available (the difference between the number of used VMs and the maximum number of VMs should be more than 1). If necessary the value “REM” for profile parameter „rdisp/max_jvm“ must be increased (see VMC Profile Parameters).

●     The VM Container uses an automatic garbage collection for managing the shared memory (Shared Garbage Collection).This is not yet active after the application server has been started, it starts working once a few applications have been executed. If possible you should not work in the escalation mode which is indicated by the display Shared GC – Active, VMs must contribute (do not confuse with the display Shared GC – Active, VMs should contribute).If the shared GC is often in the escalation mode, the configured memory area in the shared memory is too small and must be increased in the parameter vmcj/option/ps.

●     The number of Errors Occurred in the VM Overview) should be zero. However, if there are any errors you can find more information about them by choosing VMC ® Error Info.  In particular you can ascertain the work process the error occurred in, which would help SAP support to find out further information from the developer trace.

Logging

Another way of analyzing errors in the VM Container is the Java log display, which can be found in the VMC System Administration (transaction SM53) in the navigation area under Log Administration ® Log Display. Error messages can be viewed also during the Java execution. To select messages in the VM Container framework, the category System (under “/”)in the log selection should be selected. To select messages in the application which uses the VM Container, select the category Applications.  To select the error-relevant log entries, you should select the value ERROR in the Severity field.

For more information see Logging and Tracing in the VM Container.

Load Analysis

Possibilities for load analysis while the VM Container is running are described in Load Analysis in the VM Container.

Evaluation of Statistics

To perform a retrospective analysis you can use the SAP statistics. For more information see Statistics in the VM Container.