Configuration and Setup of SAP JVM

Garbage Collection and Memory Layout

One area where some configuration effort can be advantageous under certain circumstances is the choice of a garbage collector (GC) matching the application requirements and - closely connected - the partitioning of the available working memory. The following section provides a short overview of this topic and some hints and advice on useful parameters.

Generational GC

It has been empirically observed that in many programs, the most recently created objects are also those most likely to become inaccessible quickly (known as infant mortality or the generational hypothesis). A generational GC divides objects into generations. The young generation contains recently created objects. Objects which survive some young generation collections (sometimes known as small GCs) are copied (promoted) to the old generation. The permanent generation contains class metadata.

Usually objects are allocated in the young generation, the so-called “eden” space. If an allocation fails (the eden is full), all Java threads are halted and a young generation GC is invoked. All surviving objects in the young generation (eden and from space) are copied to the “to” space. “to” and “from” space are switched afterwards. If the “to” space is filled, objects are copied to the old generation. The “tenuring threshold” specifies the amount of copy steps inside the young generation before an object is promoted to the old generation.

The old generation is collected when a promotion fails. The permanent and the old generation are usually collected together. During this collection the Java threads are halted.

Choosing a GC algorithm

The young generation is collected by a “copy collector” . As described above objects are copied from “eden” and “from” to “to” space and then to the old generation. The cost of this GC is determined by the amount of objects to be copied. The workload can be distributed among a number of parallel GC threads, which speeds up the GC on multi CPU machines. Usually the pause time of a young generation collection is between about ten milliseconds and one hundred milliseconds.

The old generation is collected by a mark sweep (compact) collector. The GC time depends on the fill level of the old generation and the amount of objects swept. The GC time is roughly about 1-4s per GB. This would lead to long pause time for an ordinary stop-the-world collector. The SAP JVM offers two different old generation collectors: a stop-the-world collector, which collects and compacts the old generation with several GC threads ( -XX:+UseParallelOldGC ) and a mostly concurrent collector, which does most of the marking and sweeping concurrently to the application execution ( -XX:+UseConcMarkSweepGC ). The latter cannot compact the heap. Hence it could be that a promotion of a large object fails and a fallback to a compacting stop-the-world collector is invoked. To avoid these long running stop-the-world GCs the SAP JVM starts the concurrent old generation collection when the old generation is 80% filled.

For completeness: -XX:+UseParallelGC is a parallel young generation collector, which can be used together with -XX:+UseParallelOldGC .

Option -XX:+UseParNewGC can be used in combination with -XX:+UseConcMarkSweepGC .

Configuring the Heap and Garbage Collector

The following figure provides gives an overview of the heap parameters.

As depicted in the graphic, the following options are relevant for the GC configuration:

• -Xmx <size> : maximum size of the Java heap

• -Xms <size> : initial heap size

• -XX:MaxPermSize= <size> : maximum size of permanent generation

• -XX:PermSize= <size> : initial size of the permanent generation

• -XX:MaxNewSize= <size> : maximum size of the young generation

• -XX:NewSize= <size> : initial size of the young generation

• -XX:ParallelGCThreads= <val> : number of threads used by the GC

• -XX:MaxTenuringThreshold= <val> : maximum number of copies inside the young generation before promotion

• -XX:SurvivorRatio= <val> : ratio between eden and one survivor space. The eden is <val> times bigger than a survivor space

• -XX:TargetSurvivorRatio= <val> : desired fill level in % of a survivor space. The SAP JVM automatically adjusts the tenuring threshold (only ParNewGC)

• -XX:SoftRefLRUPolicyMSPerMB= <value> : threshold in ms per free MB for clearing unreferenced SoftReferences

• -XX:GCHeapFreeLimit= <value>

  minimum percentage of free space after a full GC before an OutOfMemoryError is thrown. Default value: 10.

• -XX:GCTimeLimit= <value>

  limit of proportion of time spent in GC before an OutOfMemoryError is thrown. Default value: 90

• -XX:{+-}UseGCOverheadLimit

  use policy to limit of proportion of time spent in GC before an OutOfMemory error is thrown. Default value: + .

For more information on monitoring the GC, see Monitoring and Management .

Setting the Debug Port Range

For security reasons, it is strongly advisable to restrict the access to the debugging port range of a running SAP JVM. Using the debugging protocol, everyone who can connect to the VM effectively gains complete control over the VM and can change its behavior, as well as read sensitive information.

For this reason, the debugging port range and the port used by jvmmond (if running) should be protected, e.g., by using a firewall.

The default debugging port range of an SAP JVM is 8000 - 8100 and can be customized by the VM parameter -XdebugPortRange: <from> [- <to> ].

The debugging port of an SAP JVM running in an application server node is derived using the formula:

5${INSTANCE_NUMBER}20 + ${NODE_INDEX} * 5 + 1

This can be configured in the AS Java Config Tool by changing the value for the key DebugPort in the VM Environment tab.

Configuring GC History

The SAP JVM offers very detailed traces with respect to garbage collection including among other things the amount of memory used in the Java heap before and after the collection or the duration and utilized CPU time of the garbage collection. This garbage collection information can be useful for a number of reasons:

• Misconfigurations concerning the garbage collectors of a JVM can cause more or less severe performance penalties. These can be diagnosed using the garbage collection traces.

• Some applications have to fulfill soft real-time requirements regarding some degree of responsiveness. Hence, garbage collections that temporarily suspend the application must not exceed some user defined limit so that the application has enough time left to meet its deadline. The garbage collection information provided by the SAP JVM simplifies the process of checking whether the pause times caused by garbage collections were sufficiently small.

• In case low memory situations occur during application execution which may ultimately lead to an OutOfMemoryError being thrown, it can be useful to inspect the garbage collection traces to distinguish temporary memory shortages from permanent ones.

• Detailed garbage collection information can be used for tuning the throughput vs. pause time of the garbage collectors.

Problems in the area of garbage collection are usually noticed some time after the actual occurrence. Therefore, the SAP JVM includes a garbage collection history feature, which continuously writes garbage collection data into a file using a compressed binary format. By use of buffering, the feature does not cause a measurable performance impact of the JVM.

The garbage collection history uses one file as storage. The file is typically used as a ring buffer, i.e. new values may overwrite older values when the file is full. A new file is created during every JVM startup (if the feature is enabled). To prevent information loss because of (several) restarts of the JVM, the JVM keeps a few backup files.

Command Line Configuration

The garbage collection history can be configured using several command line options:

• -XX:{+-}GCHistory : Enables/disables the garbage collection history (default: disabled).

• -XX:GCHistoryFilename=<file name> : Sets the name of the file used for storing the garbage collection history information. The default is sapjvm_gc.prf . A @PID in the filename will be replaced by the process identifier of the JVM and @VMID by the VM identifier.

• -XX:GCHistoryMaxFileSize=<size in bytes> : Sets the maximum size of the garbage collection history file. New values may overwrite older ones when the threshold is reached. If this option is set to zero, no maximum size is imposed. The default value is 20 MB.

• -XX:GCHistoryMaxFileCount=<number of files> : Sets the maximum number of files that are used for the garbage collection history. A new garbage collection history file is created when the JVM is restarted. The allowed range is 1..99 (default: 3). The extension .b<00..99> is added to the backup files, e.g. sapjvm_gc.prf.b00 is the newest backup file.

• -XX:GCHistoryCompressionLevel=<level> : Sets the compression level (0 is no compression, 9 is maximum compression) of the garbage collection history file. The default is 5 (medium compression, medium CPU cost).

Garbage Collection History File Retrieval

In case the corresponding SAP JVM is not running the garbage collection file can be analyzed right away. To retrieve the garbage collection history file of a running JVM process the command line and GUI versions of jvmmon include a new command retrieve complete gc history . This command copies a consistent view of the garbage collection history to a local file. The file retrieval also works for remote JVMs using jvmmond.

Displaying Garbage Collection History

The displaygchistory command line tool can be used to extract the textual representation of the garbage collection information from the garbage collection history file. The command line option -? shows the usage information of the tool.

displaygchistory can be used to display information about all or only some of the garbage collections that occurred. Furthermore, it is possible to set different levels of detail for the garbage collection output.