WebLogic Server Performance and Tuning: Part I - Tuning JVM
- by Gokhan Gungor
Each WebLogic Server instance runs in its own dedicated Java Virtual
Machine (JVM) which is their runtime environment. Every Admin Server in
any domain executes within a JVM. The same also applies for Managed
Servers. WebLogic Server can be used for a wide variety of applications
and services which uses the same runtime environment and resources.
Oracle WebLogic ships with 2 different JVM, HotSpot and JRocket but you
can choose which JVM you want to use.
JVM is designed to optimize itself however it also provides some startup
options to make small changes. There are default values for its memory
and garbage collection. In real world, you will not want to stick with
the default values provided by the JVM rather want to customize these
values based on your applications which can produce large gains in
performance by making small changes with the JVM parameters. We can tell
the garbage collector how to delete garbage and we can also tell JVM
how much space to allocate for each generation (of java Objects) or for
heap. Remember during the garbage collection no other process is
executed within the JVM or runtime, which is called STOP THE WORLD which
can affect the overall throughput.
Each JVM has its own memory segment called Heap Memory which is the
storage for java Objects. These objects can be grouped based on their
age like young generation (recently created objects) or old generation
(surviving objects that have lived to some extent), etc. A java object
is considered garbage when it can no longer be reached from anywhere in
the running program. Each generation has its own memory segment within
the heap. When this segment gets full, garbage collector deletes all the
objects that are marked as garbage to create space. When the old
generation space gets full, the JVM performs a major collection to
remove the unused objects and reclaim their space. A major garbage
collect takes a significant amount of time and can affect system
performance.
When we create a managed server either on the same machine or on remote
machine it gets its initial startup parameters from
$DOMAIN_HOME/bin/setDomainEnv.sh/cmd file.
By default two parameters are set:
Xms: The initial heapsize
Xmx: The max heapsize
Try to set equal initial and max heapsize. The startup time can be a
little longer but for long running applications it will provide a better
performance.
When we set -Xms512m -Xmx1024m, the physical heap size will be 512m.
This means that there are pages of memory (in the state of the 512m)
that the JVM does not explicitly control. It will be controlled by OS
which could be reserve for the other tasks. In this case, it is an
advantage if the JVM claims the entire memory at once and try not to
spend time to extend when more memory is needed. Also you can use
-XX:MaxPermSize (Maximum size of the permanent generation) option for
Sun JVM. You should adjust the size accordingly if your application
dynamically load and unload a lot of classes in order to optimize the
performance.
You can set the JVM options/heap size from the following places:
Through the Admin console, in the Server start tab
In the startManagedWeblogic script for the managed servers
$DOMAIN_HOME/bin/startManagedWebLogic.sh/cmd
JAVA_OPTIONS="-Xms1024m -Xmx1024m" ${JAVA_OPTIONS}
In the setDomainEnv script for the managed servers and admin server (domain wide)
USER_MEM_ARGS="-Xms1024m -Xmx1024m"
When there is free memory available in the heap but it is too fragmented
and not contiguously located to store the object or when there is
actually insufficient memory we can get java.lang.OutOfMemoryError. We
should create Thread Dump and analyze if that is possible in case of
such error.
The second option we can use to produce higher throughput is to garbage
collection. We can roughly divide GC algorithms into 2 categories:
parallel and concurrent. Parallel GC stops the execution of all the
application and performs the full GC, this generally provides better
throughput but also high latency using all the CPU resources during GC.
Concurrent GC on the other hand, produces low latency but also low
throughput since it performs GC while application executes. The JRockit
JVM provides some useful command-line parameters that to control of its
GC scheme like -XgcPrio command-line parameter which takes the following
options;
XgcPrio:pausetime (To minimize latency, parallel GC)
XgcPrio:throughput (To minimize throughput, concurrent GC )
XgcPrio:deterministic (To guarantee maximum pause time, for real time systems)
Sun JVM has similar parameters (like -XX:UseParallelGC or
-XX:+UseConcMarkSweepGC) to control its GC scheme. We can add -verbosegc
-XX:+PrintGCDetails to monitor indications of a problem with garbage
collection.
Try configuring JVM’s of all managed servers to execute in -server mode
to ensure that it is optimized for a server-side production environment.
