LinkedIn
Copied!

Table of Contents

How to set up Sun JVM v1.4.2 and v1.5

Summary

This article provides guidelines for setting up your JVM when you begin building a Process Commander application. The recommended settings and their values are intended only as starting points. The optimal JVM configuration for a given application must be determined after you have deployed it and have performed load testing.

Also described are settings to avoid because they may cause unwanted JVM behavior or conflict with the advised settings.

Important: Tune the JVM after you have resolved performance and memory bottlenecks within the application. Premature JVM tuning will likely produce sub-optimal results that do not address all performance issues.

Suggested Approach

The following settings and values apply to one or more JVMs when running in a multi-node environment in an enterprise-scale system employing multiple CPUs.

Recommended settings and starting values

Setting

Starting Value

Description

-Xms

-Xms1536m

Initial heap size *

-Xmx

-Xmx1536m

Maximum heap size

Use the same value as –Xms

-XX:PermSize

-XX:PermSize=64m

Initial size of the Permanent Generation

-XX:MaxPermSize

-XX:MaxPermSize=256m

Maximum size of the Permanent Generation
Although a value of 160MB can be used, this is usually insufficient for most enterprise-scale applications.

-XX:+UseParNewGC

N/A

Uses parallel New Generation GC

-XX:+UseConcMarkSweepGC N/A Collects the Tenured Generation and attempts to minimize GC pauses by doing most of GC work concurrently with the application thread.

Using this setting in combination with -XX:+UseParNewGC reduces GC pauses for New and Tenured objects.

-XX:SurvivorRatio

-XX:SurvivorRatio=8

JVM v1.4.2 only
Determines the size of the Eden and Survivor space

Do not use the default value, which is too small.

-XX:TargetSurvivorRatio

-XX:TargetSurvivorRatio=90

Percentage of survivor space used after GC scavenge

Increasing from 50% (the default value) improves space utilization by allowing objects to age more in the young generation before being tenured.

* 1536MB has proved to be optimal for most environments. Larger values may require additional CPU capacity and testing to ensure best performance. A Process Commander system requires, at minimum, an -Xmx value of 768MB.

About setting the size of Young Generation

-XX:NewSize and -XX:MaxNewSize settings bound the minimum and maximum sizes of Young Generation, respectively. Their sizes are computed by JVM as a function of -XX:NewRatio. By default, the setting value is 2 (a ratio of 1:2). For example, if you enter -Xms and -Xmx values to the recommended 1536MB, NewRatio sets Young Generation initial and maximum sizes to 512MB. The Tenured Generation comprises the remaining 1024MB. It is recommended that you use the default -XX:NewRatio value and not manually enter NewSize and MaxNewSize settings.

If you manually enter initial and maximum heap sizes to values other than 1536MB, be aware that JVM uses NewRatio to calculate the NewSize and MaxNewSize settings.

Settings that are not recommended

Setting

Notes

-Xmn

Returns error when used with -Xms or -Xmx

-Xns

Conflicts with NewSize & MaxNewSize

-server

No improvement achieved with this setting. In some cases, has caused system failure.

-Xnoclassgc

Likely to cause Permanent Generation to run out of space when doing rules maintenance or application deployment

-XX:+AggressiveHeap

Attempts to size the heap based on available physical memory. May grow to a size that disrupts the New to Tenured ratio of 1 to 2.

-XX:UseAdaptiveSizePolicy

Is enabled by default when using +UseParNewGC

-XX:ParallelGCThreads

JVM most effectively calculates this value

Sizing physical memory for the server

The server memory requirement is based on the number of JVMs running on your system.

  1. Calculate the following for each JVM:

    JVM memory requirement = -Xmx + -XX:MaxPermSize + 200M (for Java runtime processing)

  2. Calculate the following for your server:

    server memory requirement = nJVM memory requirement + 1 GB (for OS runtime processing)

    where n equals the number of JVMs

If the server does not have this amount of physical memory, the operating system will perform page swapping and significantly compromise performance.

Diagnostic tool settings

After you have made your initial settings,  switch on the garbage collection log file (known as the “verboseGC log” or “verboseGC file”), which collects statistics that you can use to tune and improve JVM performance.
Use the following settings::

  • -verbosegc — Prints garbage collection information. Because the level of detail is limited, this setting has low overhead and can be switched on in production environments.
  • -Xloggc:<filename> — Writes verboseGC to the specified file
  • -XX:+PrintGCTimeStamps — Adds a timestamp to the printed garbage collection information

You can generate more log file detail by adding the following parameters (which may add overhead):

  • -XX:+PrintHeapAtGC — Prints detailed garbage collection information including heap occupancy for and after GC. This parameter generates a large amount of data to the log file. Ensure there is adequate file system space when enabling this option.
  • -XX:+PrintGCDetails — Prints detailed garbage collection information
  • -XX:PrintTenuringDistribution — Prints object aging or tenuring information

To help diagnose memory problems, set the following:

  • -XX:+HeapDumpOnOutOfMemoryError — Dumps heap to file when java.lang.OutOfMemoryError is thrown
  • -XX:HeapDumpPath=<path to directory> — Defines path to directory of filename for heap dump

Related PDN Articles:

Suggest Edit

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.