How to Optimize the JVM Heap - Specifying Heap Size Values

Tuning Integration Flows 28-23

28.8 Tuning Java Virtual Machines JVMs

This section discusses how to optimize the JVM heap.

28.8.1 How to Optimize the JVM Heap - Specifying Heap Size Values

The goal of tuning your heap size is to minimize the time that your JVM spends doing garbage collection while maximizing the number of clients that the Fusion Middleware stack can handle at a given time. Specifically the Java heap is where the objects of a Java program live. It is a repository for live objects, dead objects, and free memory. When an object can no longer be reached from any pointer in the running program, it is considered garbage and ready for collection. A best practice is to tune the time spent doing garbage collection to within 5 of execution time. The JVM heap size determines how often and how long the virtual machine spends collecting garbage. An acceptable rate for garbage collection is application-specific and should be adjusted after analyzing the actual time and frequency of garbage collections. If you set a large heap size, full garbage collection is slower, but it occurs less frequently. If you set your heap size in accordance with your memory needs, full garbage collection is faster, but occurs more frequently. In production environments, set the minimum heap size and the maximum heap size to the same value to prevent wasting virtual machine resources used to constantly grow and shrink the heap. Ensure that the sum of the maximum heap size of all the JVMs running on your system does not exceed the amount of available physical RAM. If this value is exceeded, the Operating System starts paging and performance degrades significantly. The virtual machine always uses more memory than the heap size. The memory required for internal virtual machine functionality, native libraries outside of the virtual machine, and permanent generation memory memory required to store classes and methods is allocated in addition to the heap size settings. To tune the JVM garbage collection options you must analyze garbage collection data and check for the frequency and type of garbage collections, the size of the memory pools, and the time spent on garbage collection. Before you configure JVM garbage collection, analyze the following data points: ■ How often is garbage collection taking place? Compare the time stamps around the garbage collection. ■ How long is a full garbage collection taking? ■ What is the heap size after each full garbage collection? If the heap is always 85 free, for example, you might set the heap size smaller. ■ Do the young generation heap sizes Sun or Nursery size Jrockit need tuning? You can manually log garbage collection and memory pool sizes using verbose garbage collection logging: Sun JVM command line options: -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps Jrockit JVM command line options: -XXverbose:gc 28-24 Developers Guide for Oracle Application Integration Architecture Foundation Pack For example, you can use the following JVM options to tune the heap: ■ If you run out of heap memory not due to a memory leak, increase -Xmx. ■ If you run out of native memory, you may need to decrease -Xmx. ■ For Sun JVM, modify -Xmn to tune the size of the heap for the young generation. ■ For Oracle JRockit, modify -Xns:nursery size to tune the size of the nursery. ■ If your AIA service instance runs on a dedicated host, set the heap size value as high as possible but make sure it does not exceed the available physical RAM. Example 28–2 shows values suggested for 32-bit Sun JVM running on 32-bit Linux on 32-bit64-bit hardware. It also assumes that the host machine has sufficient physical RAM installed and that other OS processes are not consuming a significant portion of the available memory. It is highly recommended that the production environment has 64-bit JVM running on 64-bit hardware with atleast 4 GB of memory. The following configurations are based on assumption that the environment has atleast 3 GB of memory. Table 28–2 JVM Heap Size Values JVM Parameters Recommended Value for Production Notes Initial heap size 2048 It is recommended that Initial Heap and Maximum Heap are set to the same value for the proper memory utilization and minimize major garbage collection. A small heap becomes full quickly and must be garbage collected more often. It is also prone to more fragmentation, making object allocation slower. A large heap introduces a slight overhead in garbage collection times. A heap that is larger than the available physical memory in the system must be paged out to disk, which leads to long access times or even application freezes, especially during garbage collection. In general, the extra overhead caused by a larger heap is smaller than the gains in garbage collection frequency and allocation speed, as long as the heap does not get paged to disk. Thus a good heap size setting would be a heap that is as large as possible within the available physical memory. Maximum heap size 2048 Enable J2SE 5.0 Platform Mbeans Enable Keep it enabled, so that memory and cpu real time monitoring can be done and further tuning can be done if required. -XX:PermSize 256 This setting is used to allocate memory outside of heap space to hold java classes. Note: JRockit JVM does not have this capability. -XX:MaxPermSize 256 -XX:AppendRatio 3 None Tuning Integration Flows 28-25 Example 28–7 shows sample JVM configurations for 64-bit Sun JVM running on 64-bit Linux on 64-bit hardware having 16GB RAM. Note that settings such as heap space -mx -ms , young generation MaxNewSize NewSize, permanent size MaxPermSize, ParallelGCThreads must be adjusted according to the memory and processors available in your environment. Similarly, directory paths for several of the directives listed below must be adjusted accordingly. Example 28–7 Sample JVM Configurations data id=java-options value= -d64 -server -Doc4j.jms.implementation=oracle.j2ee.jms -Dcom.sun.management.jmxremote -mx8192M -ms8192M -XX:MaxPermSize=512M -XX:MaxNewSize=2450M -XX:NewSize=2450M -Xmn2500M -XX:SurvivorRatio=6 -XX:AppendRatio=3 -verbose:gc -XX:+AggressiveOpts -XX:+HeapDumpOnOutOfMemoryError -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+UseParallelOldGC -XX:ParallelGCThreads=8 -Xloggc:exportoracleproduct10.1.3.1OracleAS_1opmnlogsj2eegc.log -Djava.security.policy=ORACLE_HOMEj2eeOC4J_SOAconfigjava2.policy -Djava.awt.headless=true -Dhttp.webdir.enable=false -Doc4j.userThreads=true -XX:NewSize 818 Another important heap configuration is the garbage collectors generational settings. The garbage collector optimizes collection by classifying objects by how long they live. Most of the BPEL engines objects are short lived, thus they live in the Eden space. We recommend sizing the Eden space to be 40-50 of the total maximum heap size. The following command line starts Java with a Eden sizing that is 60 of the maximum heap size. Also If you are using 2 or more than 2 CPUs and it is a non-Windows machine, it is recommended to use -XX:+ AggressiveOpts jvm flag. The -XX:+ AggressiveOpts option inspects the machine resources size of memory and number of processors and attempts to set various parameters to be optimal for long-running, memory allocation-intensive jobs. Note this flag does not affect Windows performance. In JRockit JVM, young new generation is called nursery size - and it is specified using -Xnssize -XX:MaxNewSize 818 -XX:SurvivorRatio 6 -XX:+AggressiveOpts Set in the JVM argument Table 28–2 Cont. JVM Heap Size Values JVM Parameters Recommended Value for Production Notes 28-26 Developers Guide for Oracle Application Integration Architecture Foundation Pack -Doracle.mdb.fastUndeploy=60 -Doc4j.formauth.redirect=true -Djava.net.preferIPv4Stack=true -Dorabpel.home=exportoracleproduct10.1.3.1OracleAS_1bpel -Xbootclasspathp:exportoracleproduct10.1.3.1OracleAS_1bpel liborabpel-boot.jar -Dhttp.proxySet=false -Doraesb.home=exportoracleproduct10.1.3.1OracleAS_1integrationesb -Dhttp.proxySet=false -Daia.home=exportoracleAIA

28.8.1.1 Java Performance Analysis Tools

A profiler is a performance analysis tool that enables you to reveal hot spots in the application that result in either high CPU utilization or high contention for shared resources. Some common profilers are: ■ OptimizeIt Java Performance Profiler at http:www.borland.comoptimizeitoptimizeit_profilerindex.html from Borland, a performance debugging tool for Solaris and Windows ■ JProbe Profiler with Memory Debugger at http:www.quest.comjprobe, a family of products that provide the capability to detect performance bottlenecks, perform code coverage and other metrics ■ Hewlett Packard JMeter at http:www.hp.comproducts1unixjavahpjmeter, a tool for analyzing profiling information ■ VTune Performance Analyzer at http:www.intel.comsoftwareproductsvtune, a tool to identify and locate performance bottlenecks in your code ■ PerformaSure at http:www.quest.comperformasure, a tool to detect, diagnose, and resolve performance problems in multitier J2EE applications

28.9 Tuning Weblogic Application Server