WAS v8.5 > Tune performance > Tune the application serving environment > Tune the JVM

Tune HotSpot Java virtual machines (Solaris & HP-UX)

The architecture of the Sun-developed, HP-ported HotSpot JVM has evolved differently than the IBM-developed software development kit (SDK.) Its internal structure, for young or old generation and permanent regions, arises to primarily support generational garbage page, as well as other garbage page modes as necessary.

IBM recommends using the HPEL log and trace infrastructure. With HPEL, one views logs using the LogViewer command-line tool in PROFILE/bin.

• Determine the type of JVM on which the application server is running.

  Issue the java –fullversion command from within the application server app_server_root/java/bin directory. In response to this command, the application server writes information about the JVM, including the JVM provider information, into the SystemOut.log file. If the application server is running on an IBM virtual machine for Java, see the topic Tune the IBM virtual machine for Java.

• Verify the following statements are true for the system:
  1. The most recent supported version of the JVM is installed on your system.
  2. The most recent service update is installed on your system. Almost every new service level includes JVM performance improvements.

Tuning the Sun HotSpot JVM is an iterative process where the JVM configuration is developed, data gathered, primarily from verbosegc data, and then analyzed, and any configuration revisions applied on the next cycle. Perform one or more of the following steps if you need to tune your Sun HotSpot JVM.

• Provide enough Java Heap Memory.

  The Java heap memory is a reserved, contiguous set of addresses. The size of the Java heap memory is the maximum size for which the Java heap is configured. These addresses are not available for other native or system memory demands, and are maintained and managed only by the JVM because the Java heap is used for Java object storage for the lifetime of that JVM.

  When the JVM initializes, secures resources for the Java heap are obtained according to the JVM configuration settings. If insufficient memory is available, the JVM initialization fails. If inadequate memory is configured in the Java heap, the system eventually fails with an OutOfMemory report, that is typically preceded by significant garbage collection activity, during which almost no Java processing occurs.

  Sufficient consideration for the native memory needs of other components of your process must be made to accommodate running threads, storing data for I/O, and satisfying such requirements as alignment, and page size.

  The Sun HotSpot Java heap comprises two physically independent parts that you must take into consideration when we specify maximum Java heap sizes:

  • The permanent region, which is a combination of young and old generation regions that are further (subdivided into eden, survivor spaces, and tenured regions.
  • The provision memory for the Java components of this system.

  The -XX:MaxPermSize= and -Xmx (Maximum Java Heap size) parameters respectively configure the maximum size of the permanent region, where the class code and related data are logically presented as part of the old generation region but are kept physically separate, and the maximum size of the main heap where Java objects and their data are stored either in the young or old generation regions. Together the permanent region and the main heap comprise the total Java heap. An allocation failure in either of these regions either represents the inability to accommodate either all the application code or all the application data, both of which are terminal conditions, that can exhaust available storage, and cause an OutOfMemory error.

  Consult these tuning parameters:

  • -XX:MaxPermSize (Permanent region)
  • -Xmx (Maximum Java Heap size)

• Disable explicit garbage page to eliminate any unnecessary or mistimed major garbage page cycles that might be introduced in software components of the system.

  Consult the tuning parameter -XX:+DisableExplicitGC.

  By default, the JVM unloads a class from memory whenever there are no live instances of that class left. We can use the -Xnoclassgc argument to disable class garbage page. However, the performance impact of class garbage page is typically minimal, and turning off class garbage collection in a Java EE based system, with its heavy use of application class loaders, might effectively create a memory leak of class data, and cause the JVM to throw an Out-of-Memory Exception.

  If we use the -Xnoclassgc argument, whenever we have to redeploy an application, you should always restart the application server to clear the classes and static data from the pervious version of the application.

  If we use the -Xnoclassgc argument, whenever we have to redeploy an application, you should always restart the application server to clear the classes and static data from the pervious version of the application.

• Tune region sizes to optimize garbage page action.

  Any garbage page tuning endeavour decisions should be based on the behavior of the garbage collectors. You should identify the correct garbage page mode to suit the operational needs of you application. You should also verify that you are meeting your performance requirements, and are efficiently recycling enough memory resources to consistently meet the demands of the application. Any changes that you make to garbage page parameter settings should produce sufficiently different results and show benefits that are derived from exploiting different regions of the HotSpot Java heap.

  An unwise choice typically lengthens the tuning process as the iterative tuning process needs to be substantially repeated. Further sections present the two principal choices, parallel throughput or concurrent low-pause, and the relevant options for further tuning. Both modes offer the potential for high performance, but the key performance factor is the behavior that gets optimized is different for each mode.

  The dominant tuning activity concerns controlling resource utilization to service allocation activity of the application, and to arrange efficient garbage page to recycle storage, as required. Inevitably, these tuning discussions are dependent on the garbage page mode employed. Two types of garbage collection are discussed:

  • The throughput collector that performs parallel scavenge copy collection on the young generation. This type of garbage page is the default type on multi-processor server class machines.
  • A concurrent low-pause collector.

  The objective of tuning with these collectors is to deliver the behavior that is most suited for the allocation patterns and object lifetimes of the application system, and that maximizes the efficiency of their collection actions.

  • Option 1: Use the default throughput/parallel scavenge collector with built-in tuning enabled.

    Starting with v5, the Sun HotSPot JVM provides some detection of the operating system on which the server is running, and the JVM attempts to set up an appropriate generational garbage page mode, that is either parallel or serial, depending on the presence of multiple processors, and the size of physical memory. It is expected that all of the hardware, on which the product runs in production and preproduction mode, satisfies the requirements to be considered a server class machine. However, some development hardware might not meet this criteria.

    The behavior of the throughput garbage collector, whether tuned automatically or not, remains the same and introduces some significant pauses, that are proportional to the size of the used heap, into execution of the Java application system as it tries to maximize the benefit of generational garbage collection. However, these automatic algorithms cannot determine if your workload well-suits its actions, or whether the system requires or is better suited to a different garbage page strategy.

    Consult these tuning parameters:

    • -XX:+UseParallelGC
    • -XX:+UseAdaptiveSizePolicy
    • -XX:+AggressiveHeap

  • Option 2: Use the default throughput/parallel scavenge collector, but tune it manually.

    Disadvantages of using the built-in algorithm that is established using the -XX:+UseAdaptiveSizePolicy parameter, include limiting what other parameters, such as the -XX:SurvivorRatio parameter, can be configured to do in combination with the built-in algorithm. When we use the built-in algorithm, you give up some control over determining the resource allocations used during execution. If the results of using the built-in algorithm are unsatisfactory, it is easier to manually configure the JVM resources, than to try and tune the actions of the algorithm. Manually configuring the JVM resources involves the use of half as many options as it takes to tune the actions of the algorithm.

    Consult these tuning parameters:

    • -XX:NewRatio=2 This is the default for a server that is configured for VM mode
    • -XX:MaxNewSize= and -XX:NewSize=
    • -XX:SurvivorRatio=
    • -XX:+PrintTenuringDistribution
    • -XX:TargetSurvivorRatio=

  • Option 3: Use the concurrent low-pause mark-sweep collector

    This collector is a radical departure from the evolution of generational garbage page that has under pinned the Hotspot architecture, permitting the overlap of application thread processing with a dedicated low-priority, background garbage page thread. If the application data is incompatible with the behavior of the default throughput collector, then the concurrent mark-sweep (CMS) collector might be a viable strategy, particularly for application systems that are intolerant of invasive pauses. This collector is particularly helpful with the very large heaps used with the 64-bit JVM, or applications that have a large set of long-lived data, also referred to as a large tenured generation, and that maintains comparatively good cache utilization, largely preserving pages of the young generation, even while the background thread must scan through all the pages of the entire heap.

    To employ the concurrent mark-sweep collector as the principle housekeeping agent, add this option, instead of any other garbage page modes, to your JVM configuration.

    Consult these tuning parameters:

    • -XX:+UseConcMarkSweepGC
    • -XX:CMSInitiatingOccupancyFraction=75
    • -XX:SurvivorRatio=6
    • -XX:MaxTenuringThreshold=8
    • -XX:NewSize=128m

    Among the difficulties for tuning with CMS, is the worst case garbage page times, which is when the CMS cycle aborts, can take last several seconds, which is especially costly for a system that uses CMS precisely to avoid long pauses. Consequently, service level agreements might dictate the use of CMS, because the average or median pause times are very, very low, and the tuning must err on the cautious side to ensure that CMS cycles don't abort. CMS succeeds only when its anticipatory trigger ensures the CMS cycle always starts early enough to ensure sufficient free resources are available before they are demanded. If the CMS collector is unable to finish before the tenured generation fills up, the collection is completed by pausing the application threads, which is known as a full collection. Full collections are a sign that further tuning is required to the CMS collector to make it better suit the application.

    Finally, unlike other garbage page modes with a compaction phase, the use of CMS theoretically raises the risk of fragmentation occurring with the HotSpot. However, in practice this is rarely a problem while the collection recovers a healthy proportion of the heap. In cases when the CMS fails, or aborts a collection, an alternative compacting garbage page is triggered. Inevitably any other type of garbage collection incurs a significant invasive pause compared to a normal CMS collection.

    As with the throughput collector, there are considerably more options available for explicitly controlling CMS. However, those mentioned represent the core of the options that you are likely to need to considered using when we are tuning the HotSpot JVM.

Gather and analyze data to evaluate the configuration, typically using verbosegc. Continue to gather and analyze data as you make tuning changes until you are satisfied with how the JVM is performing.

Subtopics

• Sun HotSpot JVM tuning parameters (Solaris and HP-UX)
  Tuning a Sun HotSpot JVM is an iterative process where the JVM configuration is developed, data is gathered, primarily the verbosegc data, and then analyzed. Any configuration revisions are then applied on the next cycle. Even though there are many Sun HotSpot JVM parameters, the following parameters have been identified as central to tuning. Which of these parameters you modify depends on your configuration choices. Therefore, in addition to reviewing these parameter descriptions, it is strongly recommended that your read the topic "Tuning Sun HotSpot Java Virtual Machines (Solaris & HP-UX)" for a complete understanding or the JVM tuning methodology.

Related

Tune the application serving environment

Reference:

Sun HotSpot JVM tuning parameters (Solaris and HP-UX)

+

Search Tips   |   Advanced Search