Garbage Collection, Tuning and Monitoring JVM in EBS 11i and R12

Garbage Collection, Tuning and Monitoring JVM in EBS 11i and R12 Siddharth Gandhi Nov 2008

Garbage Collection, Tuning and Monitoring JVM in EBS 11i and R12

1

Contents Garbage Collection, Tuning and Monitoring JVM in EBS 11i and R12..........................1 Introduction.......................................................................................... ...................3 First Steps.......................................................................................................... ......4 Memory management.............................................................................................4 Garbage Collection Concepts..................................................................................5 Definition....................................................................................................... .......5 Generations................................................................................................. .........5 Types of Collectors...............................................................................................6 Measurement.......................................................................................................6 Few notable JVM parameters...................................................................................8 Monitor the JVM............................................................................. ........................10 Future changes - JRockit........................................................................................13 References and Quotes.......................................................................................... 14 Appendix.................................................................................... ...........................15

Garbage Collection, Tuning and Monitoring JVM in EBS 11i and R12

2

Introduction In many of our support tickets we might have encountered performance and memory issues with the middle-tier and the ubiquitous java.lang.OutOfMemoryError(s) statement in our stack trace. We might be encountering these performance issues for many reasons impacted by hardware (specifications, networking etc) or software (OS, application versions/patches/parameters) or just by external parameters like user behavior, current number of active users, bandwidth etc. In the Oracle Application ‘development’ space, plugging in these performance and memory issues will majorly boil down to JVM tuning, stopping memory leaks, JDBC optimizations and few others. In this whitepaper, we will brief upon

•

Garbage Collection,

•

Tuning JVM for better performance,

•

Understanding few of the JVM tuning parameters provided in Jserv.properties and opmn.xml file

•

Monitoring JVM

The document focuses only on the OACoreGroup JVM and not considers the JVM settings for other Oracle services like Forms & Reports, Discoverer, Configurator etc. Also assumed is that the reader has some familiarity with Java and E-Business Suite 11i and Release 12

Garbage Collection, Tuning and Monitoring JVM in EBS 11i and R12

3

First Steps Quoting Sun’s documentation, Out of Memory (OOM) errors are usually thrown… “… when the Java Virtual Machine cannot allocate an object because it is out of memory, and no more memory could be made available by the garbage collector.” And so follows the usual fix of increasing the JVM heap size, java -Xms1024M -Xmx1024M ….

But in this quick-fix world, we comfortably forget the following two important questions,

1. Why Java Virtual Machine is out of memory? 2. Why garbage collector is not able to make more memory available? Let’s remember the fact that physical memory is limited and on the other hand there are easier, faster and cheaper approaches to consider then upgrading the hardware. So before we proceed to tune our JVMs, let’s brush our basics for memory management and role of Garbage Collection (GC)

Memory management “Memory management is the process of recognizing when allocated objects are no longer needed, deallocating (freeing) the memory used by such objects, and making it available for subsequent allocation“ Explicit Vs. Automatic Memory Management Java employs automatic memory management unlike C and few other programming languages where memory management is developer responsibility. Explicit management many a times results into unexpected or erroneous program behavior and crashes. Whereas automatic management is handled by a program called a garbage collector (GC). GC automatically frees all memory no longer referenced. There are basically two ways you can alter the JVM’s behavior to improve performance. Firstly, you can influence memory use by changing how memory is allocated and organized by the JVM. Secondly, you can influence how garbage collection is performed.

Garbage Collection, Tuning and Monitoring JVM in EBS 11i and R12

4

Garbage Collection Concepts

Definition Objects that are referenced are said to be live. Objects that are no longer referenced are considered dead and are termed garbage. The process of finding and reclaiming the space used by these objects is known as garbage collection. The timing of garbage collection is up to the garbage collector.

Generations Memory in the Java HotSpot virtual machine is organized into three generations:

1. Young generation, 2. Old generation(or Tenured), and 3. Permanent generation (or Perm) This generational garbage collection, takes advantage of the observation that, most programs create: • •

Many objects that have short lives (for example, iterators and local variables). Some objects that have very long lifetimes (for example, high level persistent objects)

The young generation consists of an "eden space" and two "survivor spaces." The VM initially assigns all objects to the Eden space, and most objects die there. When the young generation area fills up, it causes Minor Garbage Collection. Any objects survived after Minor GC is moved to Tenured Generation. And when Tenured Generation area fills up it causes Major Garbage Collection i.e. Full GC. Major GC is slow and expensive as compared to Minor GC since it involves evaluating all live objects. The permanent generation holds objects that the JVM finds convenient to have the garbage collector manage, such as objects describing classes and methods, as well as the classes and methods themselves.

Figure 1

Garbage Collection, Tuning and Monitoring JVM in EBS 11i and R12

5

Types of Collectors To reclaim memory, HotSpot has four different collectors as of J2SE 5.0 (and the option to enable them): • • • •

The default or serial collector Throughput collector (-XX:+UseParallelGC) Concurrent low pause collector (-XX:+UseConcMarkSweepGC) Incremental collector (-XX:+UseTrainGC)

The default collector is a serial collector that pauses the application during minor and major collections. If the host machine has a single CPU, the serial collector will likely be as fast or faster as the other collectors. The throughput collector uses the same collection mechanism as the serial collector for major collections, but implements a parallel minor collector for the young generation space. On the other hand, the concurrent low-pause collector attempts to perform most of the work of a major collection without interrupting your application (pauses are low/short). Finally the incremental collector, by careful book-keeping, collects just a portion of the tenured generation at each minor collection, trying to spread the large pause of a major collection over many minor collections. However, the incremental collector is deprecated and will eventually be removed. Which collector works best for your application depends on the load of the application and the host system. However, unless you have a system with multiple CPUs, tuning memory configuration rather than garbage collection is likely to yield performance gains.

Measurement Before we consider the metrics, let’s understand various parameters, on which it’s evaluated. Throughput is the percentage of total time not spent in garbage collection, considered over long periods of time. Pauses are the times when an application appears unresponsive because garbage collection is occurring. Usually tolerable, but in an interactive graphics program even short pauses may negatively affect the user experience. Promptness is the time between when an object becomes dead and when the memory becomes available, an important consideration for distributed systems, including remote method invocation (RMI). Footprint is the working set of a process, measured in pages and cache lines. On systems with limited physical memory or many processes, footprint may dictate scalability.

Garbage Collection, Tuning and Monitoring JVM in EBS 11i and R12

6

Throughput and footprint are best measured using metrics particular to the application. On the other hand, pauses due to garbage collection are easily estimated by inspecting the diagnostic output of the virtual machine itself. Now let’s understand that how and what garbage collection details are generated in the E-Business Suite. Table 1 below briefs how and where to set the parameters in the appropriate file to generate the GC data and view it for specific E-Business Suite version Table 1 Suite

Generate the GC data

View the output {file location}

11i

Provide the command line argument -verbose:gc in the file $IAS_ORACLE_HOME/Apache/Jserv/etc/jserv.properties. For instance,

$IAS_ORACLE_HOME/Apache/Jserv/l ogs/jvm/OACoreGroup..stdout

wrapper.bin.parameters=-verbose:gc -hotspot -Xmx1024M -Xms128M -XX:MaxPermSize=128M or value of the s_jvm_options context variable in the file $APPL_TOP/admin/.xml verbose:gc -Xmx512M -Xms128M -XX:MaxPermSize=128M R12

Set the argument -verbose:gc in the start-parameters, javaoptions element in the file $ORA_CONFIG_HOME/10.1.3/opmn/conf/opmn.xml. For instance,

$LOG_HOME/ora/10.1.3/opmn/OC4J~ oacore~default_group_*