JVM Tuning CheatSheet
This diagram is designed for the Sun hotspot
In fact, many JDK1.6 users need no tuning at all – the JVM picks good defaults and ergonomics does a decent job. Follow this only if the default behavior is not good enough (for instance, frequent garbage collections, low throughput, long GC pauses, etc).
This diagram is designed for the Sun hotspot
In fact, many JDK1.6 users need no tuning at all – the JVM picks good defaults and ergonomics does a decent job. Follow this only if the default behavior is not good enough (for instance, frequent garbage collections, low throughput, long GC pauses, etc).
Can
be broadly categorized in to 4 sections
1.
GC (Garbage
Collection
The garbage collection algorithm is
one of the two mandatory tunables for java performance tuning. Start with UseParallelOldGC.
If GC pauses are not acceptable, switch to UseConcMarkSweepGC (prioritizes
low application pause times at the cost of raw application throughput). Specify
parameter ParallelGCThreads to limit GC threads
(yes limit, the default is usually too high for multiple
Weblogic servers sharing a large, multi-core machine). Recommendations for
values and other flags will be covered later
2.
Tuning the Heap
This is the other mandatory tunable.
I’m using ‘heap’ as an umbrella term for all Java memory spaces.
Technically, Perm and Stack are not part of the java heap in Sun hotspot. Required
flags in my tuning exercise are total heap size (Xmx, Xms),
young generation size (Xmn) and permanent generation size (PermSize, MaxPermSize). Xss tuning
is optional. I only use it when tuning on a 32-bit heap-constrained JVM;
reducing Xss only to squeeze memory out from native space so more is available
for Xmx. In any case, never set Xss below 128k for Fusion Middleware (default
is usually 512k to 1m depending on OS)
3.
GC Logging
GC logging is mandatory only for the
duration of the tuning exercise itself. However, due to its low overhead
(typically only one line written per collection, which itself is relatively
infrequent), it is highly recommended for production as well. Otherwise, you
will not be able to make an educated tuning decision if/when things don’t work
as expected.
4.
Perfomance(Optional)
These are only used for fine tuning
when performance is the driver for the tuning exercise. Even then, try these
only after GC and heap are well tuned to begin with
Requirement that warrants JVM tuning
in production Oracle Fusion Middleware is not performance, rather unacceptable
GC pauses. The cultprit almost always is a Full GC that causes long application
pause. Symptoms include temporarily unresponsive servers, client session
timeouts, etc. If you’re capturing GC logs using the flags in the diagram, a
search for “Full GC” will show how many, how frequent and how long Full GC’s
took. Following the tunables in the diagram above, this is how you can solve
the problem
