6.1 Configuring the Java Virtual Machine

In general, a program written in Java usually requires more memory than the same program written in C. However, programs written in Java can be more robust at an earlier phase of the development cycle, because of the design of the language and the runtime environment.

When running a program written in C, you do not specify how much memory that program uses. Most of these programs obtain additional memory from the operating system as they need it. There is no fixed upper limit, other than the operating system’s maximum allowance.

Java, in contrast, requires declaring the maximum amount of memory to use. This can be set to a very high number, such as 2 or 3 gigabytes, but there are reasons why this might not be a good idea.

When the Java virtual machine starts, it allocates a portion of memory from the operating system. The size of memory allocated is usually 8MB, unless it is told to allocate more.

The Java virtual machine has an inherent runtime overhead, which can amount to quite a bit of memory. There is no direct way to control the size of this overhead. Recognize that if a parameter is passed to the Java virtual machine instructing it to use 2 gigabytes of memory, the result can be, according to various utilities, that the virtual machine uses more than 2 GB. This is normal and should be expected.

If a maximum memory usage has been set, the virtual machine usually does not need all the memory right away and won’t allocate it from the operating system. Instead, the virtual machine determines how much of its heap space allocated from the operating system should actually be used for Java objects.

If this is less than 30%, memory is released back to the operating system. If it is more than 70%, the virtual machine asks the operating system to give it another chunk of memory (usually a fairly large chunk). If the virtual machine has reached the maximum heap size provided, it does not ask the operating system for more memory.

Windows restricts application address space to two (2) gigabytes regardless of the amount of memory available. Java, which consists of heap and nonheap memory, requires a maximum size of 1.7 gigabytes that is a contiguous block. Often this amount of contiguous memory is not available. This causes the actual size to be between 1.2 and 1.5 gigabytes.

If you require more memory, you must use a 64‑bit OS and JVM or use Linux on x86 to have 3 gigabytes heap memory available since these systems are not limited by Windows restriction.

Garbage collection is usually triggered by a Java program allocating an object as follows:

Object allocation is actually fairly complicated and breaks down something like this:

This is a simplified model of what happens, but it is fairly close to reality.

The Java VM maintains the NG and OG areas of the heap. The maximum amount of memory that the VM uses in the new generation can be controlled with the ‑XX:MaxNewSize=size parameter. This permits the VM to use extra memory for the new generation.

The following table lists the basic parameters used to control the behavior of the VM.

The ‑Xms parameter can instruct the virtual machine on how much memory to initially allocate. The ‑Xmx parameter instructs the virtual machine how much memory, at most, it is allowed to use.

In most Operations Center installations, use the ‑Xmx and ‑XX:MaxNewSize parameters, and possibly the ‑Xms parameter.

The following table lists the Windows and UNIX defaults for the memory parameters for the Operations Center components.

*For more information about the Event Manager, see the Operations Center Event Manager Guide.

**The Remote Container server parameter is applicable only for an installation that is running as a Remote Container. For more information on Remote Container, see the Operations Center Adapter and Integration Guide.

The default can be changed in the Updating Server Settings Using the Configuration Manager. It is the Java Runtime Option for each component and is listed on the Java Runtime pane under the Tasks tab.

Before changing the memory parameters from the default values, determine how the Operations Center software uses memory. Monitor the fsgc.log file to determine what is being used. This file contains all garbage collection action.

Check the amount of physical memory on the machine — do not take logical or paged memory into consideration as these do not help Java. Find out the amount of memory that a Operations Center installation needs to run, then set the maximum memory size to a value larger than this. Then, select an appropriate new generation size.

Also check the daemon.trc file. If there is an OutOfMemoryError in the daemon.trc file originating from Operations Center software, it is usually an indicator that too little memory is provided to the Java VM. If Operations Center software tries to allocate a very large amount of memory by mistake or there are certain kinds of IO errors, you also receive an OutOfMemory message.

To determine how much memory to give Operations Center software, it is necessary to try and determine the working set size.

While monitoring the fsgc.log file, look for any collection times that exceed 15 seconds or so; this signifies a potential problem. Follow the steps to the right to maintain consistently.

To determine Operations Center software’s working set size:

Note that no operating system tools have been used to make these determinations.

On Solaris, use the prstat command to get a better view of memory usage. The most significant reason to do this is to see if there are other processes on the box using memory. Also use the Windows task manager to look at memory usage, but be careful because there is additional overhead included in the form of overhead of the VM.

The operating system tools can provide an idea of the amount of additional memory that the Java VM uses, over and above the amount provided to it with the ‑Xmx flag. The following is a sample fsgc.log output:

28.8972: [Full GC 4554K->4117K(5164K), 0.2139931 secs]
29.2526: [GC 4885K->4689K(7696K), 0.0138604 secs]
29.4526: [GC 5457K->5141K(7696K), 0.0220587 secs]
29.7094: [GC 5909K->5448K(7696K), 0.0169052 secs]
29.9499: [GC 6216K->5851K(7696K), 0.0221319 secs]
30.4152: [GC 6619K->6161K(7696K), 0.0179718 secs]
30.7133: [GC 6929K->6473K(7696K), 0.0180727 secs]
31.0125: [GC 7241K->6779K(7696K), 0.0182593 secs]
46.1367: [GC 7547K->6886K(7696K), 0.0117085 secs]
46.6746: [GC 7654K->6950K(7824K), 0.0089098 secs]
46.6837: [Full GC 6950K->6711K(7824K), 0.2935672 secs]
47.3671: [GC 7863K->6807K(12468K), 0.0049070 secs]
47.5725: [GC 7959K->6903K(12468K), 0.0055085 secs]
47.782: [GC 8055K->6997K(12468K), 0.0055513 secs]
48.0569: [GC 8149K->7093K(12468K), 0.0056057 secs]
48.4355: [GC 8245K->7188K(12468K), 0.0052199 secs]
78.6111: [Full GC 7830K->6281K(12468K), 0.2208297 secs]

The above example is from a small program run. Each Java VM produces different output, but the form should remain similar to this. Watch for the highest full GC number. In the above example, it is 6281K and the VM has a 12468K heap allocation size, at that point. Within the full GC line, additional information might be available and nested in brackets, such as:

78.6111: [Full GC [New 50k->16k(64K)] (7830K->6281K(12468K), 0.2208297 secs]

The total heap size (last bracketed number) should be the largest number.

The bottom line is:

Before varying from this, enlist some development support, then have at least two people study the fsgc.log file to determine if there is a problem that can be fixed with other flags.

If an error message logged to the formula.trc file is similar to:

java.lang.OutOfMemoryError: PermGen space

then add the following JVM parameter for the Operations Center server:

‑XX:MaxMetaSpaceSize=sizem Replace size

with a value greater than the default 128, where size represents that value. Note that the “m” is added to the value to represent megabytes.

For example:

‑XX:MaxMetaSpaceSize=128m ‑XX:MaxMetaSpaceSize=256m