Introducing Identifiers, Parameter Evaluation, and Memory Consumption

This lesson explains the significance of the Instance ID and the order the system evaluates parameters and where these are stored.

Understand the Instance ID

To find the right place where to begin the configuration you need to understand the Instance ID.

Each SAP Java system contains the so-called box number, which is composed by 3 values: <SID> + <Instance Number> + <Hostname>. The Java ID is then generated from the box number.

The table above shows the information of each system and the ID they generated, which is stored at database level.

Hint

In case of an inconsistency in the box number or with the instance ID during a system copy, Software Provisioning Manager 1.0 SP10 and higher offers the option to easily correct it in your system.

Understanding the Parameter Evaluation Sequence

SAP systems can consist of an ASCS instance and one or more application server instances. We are focusing here on Application Server Instances because we want to configure Server notes.

A SAP instance is started with an operating system user (Windows: SAPService<SID> or Unix: sap<sid>). It's environment variables are evaluated when a SAP instance is started.

Also the SAP Java system and its instances are configured by profile parameters that are stored in profile files like SAP ABAP Systems. You differentiate between the default profile, and instance profiles. The profiles get's generated during SAP Installation.

When configuring Java Server Processes you find a Template within the Configuration Tools which can be changed in the Template Custom sections.

Each Instance passes the parameter to the Instance Default which can be changed in the Instance Custom sections.

Most of the configuration effort in connection with Java server processes arises on the template custom or instance custom level. Rather in exceptional cases, parameters are stored in the profiles.

Java Instance Homogeneity

The Java instance itself is homogeneous - all server processes running inside it have the same components deployed on each one of them. Moreover, they have the same:

• Configuration: all server processes use the same configuration template and share the instance custom settings
• Lifecycle: The status of all components is the same. When one component is started/stopped on one server process, it is started/stopped on all server processes in the Java instance. Hence, to guarantee homogeneity, if one component fails to start on one server process, it is stopped on all server process.

In the tool used, the presentation of the template custom and the instance custom differs.

A number of terms for the memory management of an SAP Java Virtual Machine (SAP JVM) are explained in the following sections in a simplified form. The configuration of the VM parameters will then be discussed.

The memory area of a Java Virtual Machine (JVM or VM) is mainly divided into three areas, which are called the young generation, the tenured generation, and the Metaspace. The differences between the "generations" are discussed in more detail later. We will first consider the commonalities, however. A "generation" reserves space in the address area of the host. The Metaspace handles the memory management in a different way, this will be discussed later.

On start-up, the Virtual Machine allocates operating system memory for each "generation". Each "generation" has a initial size and a max size (maximum size). However, on start-up the VM allocates the maximum of memory for each "generation" from the operating system.

First, the VM uses the memory of the initial size. Once the initial space has been used, the VM allocates further memory space in stages up to a maximum amount. This is a pure internal allocation, the maximum memory was allocated from the operating system at start-up already.

The VM automatically takes care of the allocation of memory space for Java applications. The memory space is implicitly assigned when an object is created. Even if a large amount of memory is required, this does not mean that the system is at risk. The VM determines which objects are no longer used and releases the memory areas which they currently occupy. This task is performed by the Special Java Agent names Garbage Collector (GC) which forms part of the VM. Its job is to prevent the occurrence of situations in which there is a danger of memory bottlenecks.

The memory space that is available is called the available memory or allocated memory. Since this space is reserved by the operating system, it is also referred to as "reserved" space since the entire space up to the maximum size is "available". The space that is not yet reserved is called virtual memory. However, this should not be confused with the "virtual memory" of the operating system. If less space is required, the memory is returned to the operating system, also in stages. See the figure "Terms in Memory Space Management" also.

The reserved memory space (available memory) is potentially available to the VM. However, it does not have to be used in full. The memory space that is actually used by Java applications is referred to as used memory.

The three main memory areas of the VM, the "young, tenured", and "Metaspace" differ from one another due to the data stored in them. The objects that have been newly created by the applications are stored in the young generation. Objects that have been required for a longer period of time by an application are automatically moved to the tenured generation. The newer objects are in the "young generation" and the older objects are in the "tenured generation". Objects that are permanently required by the VM, such as classes and methods, are stored in the "Metaspace". Objects that are no longer required by the applications are automatically removed from the "generations". This process is known as garbage collection.

As you already know from the subsection "Memory Allocation Terms", the "generations" have an initial and a maximum size. For the "young generation", you can define the "initial size" with the parameter -XX:NewSize, and the "max size" with the parameter -XX:MaxNewSize. You cannot directly define the initial and maximum sizes of the "tenured generation". These are calculated from the parameters for the "young generation" and the parameters -Xmx and -Xms. The parameter -Xmx is called the "max heap size" and defines the total size of the "young" and "tenured generations". The parameter -Xms is called the "start heap size" or "initial heap size" and defines the total initial size of the "young" and "tenured generations". See also the figure "Memory Allocation of the Java VM (Simplified)".

The "Metaspace" has a different behavior than the generations. During the start, the generations allocate the maximum memory from the operating system. The "Metaspace" only allocated the minimum memory from the operating system. So if the "Metaspace" needs more memory he allocated more from the operating system. This behavior allows the Metaspace to shrink back to the minimum again. By default, the parameter -XX:MetaspaceSize is not specified, so the default value of 21MB is used. During the start of the JVM the Garbage-Collections for the "Metaspace" can occur with the "perm gen low on memory" message. This is not critical and has no performance impact as this kind of Garbage-Collections are running in parallel to the application. However, if you will reduce this messages during the start of the JVM you can set the parameter -XX:MetaspaceSize to "256m". In earlier versions of the JVM there was a "perm generation" with the same behavior as the "young" or "tenured generation". This "perm generation" is replaces by the "Metaspace" even if the parameters for the "perm generation" are still visible in the template, but they are ignored by the JVM. For more information see SAP Note "2121243 - SAP JVM PermGen removal"

In addition to the memory area for the "generations", the VM also reserves space for its processes and threads.

After this brief introduction to the basic terms of the SAP JVM, we can now take a look at the configuration of the VM parameters.