JVM settings: Handy hints

The Java Virtual Machine (JVM) is a virtual “execution engine” instance that executes the bytecodes in compiled Java class files. Java programs are compiled into a form called Java bytecodes. To the JVM, a stream of bytecodes is a sequence of instructions.

Tuning the JVM to achieve optimal application performance is one of the most critical aspects of WebLogic Server performance.

Oracle recommends to use:
• Oracle JRockit JVM for production servers
• Sun HotSpot JVM for development servers and for running other WLS utilities

Setting Weblogic Server JVM Arguments:

If we want to use different JVM after domain creation is possible by setting some WLS JVM arguments.

Start JVM with Custom JVM settings.

export JAVA_VENDOR=”Oracle”
export USER_MEM_ARGS=”-Xms512m –Xmx1g”
./startWebLogic.sh

• “Oracle” indicates that you are using the JRockit SDK. It is valid only on platforms that supportJRockit.
• “Sun” indicates that you are using the Sun SDK.
• “HP” and “IBM” indicate that you are using SDKs that Hewlett Packard or IBM have provided. These values are valid only on platforms that support HP or IBM SDKs.

Basic Sun JVM Arguments :

• -XX:NewSize (default 2 MB): Default size of new generation (in bytes)
• -XX:MaxNewSize: Maximum size of new generation (in bytes). Since 1.4, MaxNewSize is computed as a function of NewRatio.
• -XX:NewRatio (default = 2): Ratio of new to old generation sizes
• -XX:SurvivorRatio (default = 8): Ratio of Eden size to one survivor space size.
• -XX:TargetSurvivorRatio (default = 50%): Desired percentage of survivor space used after scavenge
• -XX:MaxPermSize: Size of the permanent generation

Basic JRockit JVM Arguments:

• -Xms The initial amount of heap allocated to the JVM
• -Xmx The maximum amount of heap that this JVM can allocate
• -Xns Size of the nursery generation in the heap
• -XgcPrio A priority level that helps to determine which GC algorithms the JVM will use at run time:
• throughput: Maximize application throughput
• pausetime: Minimize how long GC runs
• deterministic: Consistent response times
• -XXcompactRatio The percentage of the heap

Common JVM Issues:

Out of Memory : JVMs trigger java.lang.OutOfMemoryError when there is insufficient memory to perform some task . An out-of-memory condition can occur when there is free memory available in the heap but it is too fragmented and not contiguously located to store the object being allocated or moved (as part of a garbage collection cycle).

Memory Leak : Are a common cause of out-of-memory errors, can occur because of excessive caching.

JVM Crash: We can identify and troubleshoot a JVM crash by the diagnostic files that are generated by the JVM. A snapshot is created
that captures that state of the JVM process at the time of the error.

This binary file contains information about the entire JVM process and needs to be opened using debugging tools.
The gdb debugging tool, popular on Linux, can extract useful information from core files. The Dr.Watson tool on Windows provides similar capabilities.

On the Sun JVM, the log file is named hs_err_pid.log, where is the process ID of the process. JRockit refers to this error log as a “dump” file, and is named jrockit..dump.

Basic JVM Tools:
– Stack Trace
– Thread Dump
– Verbose GC
– Sun Profiler Agent
– Sun Diagnostic Tools
– JVisualVM