Why Teams call analytics are critical to your entire business
Basics of JVM Tuning
1. A D I G I TA L C O M M E R C E C O N S U LTA N C Y
2. Basics of JVM Tuning
... because out-of-the-box is often not enough
Vladislav Gangan
Vice President of Engineering
Tacit Knowledge, Moldova
3. AGENDA
• Basics of JVM memory management
• Optimal starting settings for tuning
• Garbage collection algorithms
• Debugging the garbage collection process
• Putting theory in practice
5. TWO AREAS OF MEMORY - STACK
• scratch space for thread
execution
• easy to track internally
• any method call results in
block allocation
• local vars
• bookkeeping data
• always LIFO allocation
6. TWO AREAS OF MEMORY - STACK
• scratch space for thread
execution
• easy to track internally
m2 vars
• any method call results in
block allocation m1 vars
• local vars
• bookkeeping data
• always LIFO allocation
7. TWO AREAS OF MEMORY - STACK
• scratch space for thread
execution
• easy to track internally
free
• any method call results in
block allocation m1 vars
• local vars
• bookkeeping data
• always LIFO allocation
8. TWO AREAS OF MEMORY - STACK
• scratch space for thread
execution
• easy to track internally
m3 vars
• any method call results in
block allocation m1 vars
• local vars
• bookkeeping data
• always LIFO allocation
9. TWO AREAS OF MEMORY - STACK
• scratch space for thread
execution
• easy to track internally m4 vars
• any method call results in m3 vars
block allocation
• local vars m1 vars
• bookkeeping data
• always LIFO allocation
10. TWO AREAS OF MEMORY - HEAP
• dynamic & random memory
allocation
• much more complex to
handle
• can result in memory leaks if
objects not destroyed properly
• shielded from the
developer by the JVM
11. TWO AREAS OF MEMORY - HEAP
• dynamic & random memory
allocation o1
• much more complex to
handle
• can result in memory leaks if
objects not destroyed properly
• shielded from the
developer by the JVM
12. TWO AREAS OF MEMORY - HEAP
• dynamic & random memory
allocation o1
• much more complex to o2
handle
• can result in memory leaks if
objects not destroyed properly
• shielded from the
developer by the JVM
13. TWO AREAS OF MEMORY - HEAP
• dynamic & random memory
allocation o1
• much more complex to o2 o3
handle
• can result in memory leaks if
objects not destroyed properly
• shielded from the
developer by the JVM
21. GARBAGE COLLECTION TYPES
• Minor collection
• operates on young space
• low impact on performance
• Major collection
• operates on entire heap
• very costly performance wise
• some algorithms are “stop-the-world” activity
24. HEAP SIZE DEFAULTS
Non-server class
machine (or 32-bit
Heap setting Server class machine
Windows) or prior to
to J2SE 5.0
1/64 of
-Xms 4 MB physical
(up to 1 GB)
1/4 of physical
-Xmx 64 MB
(up to 1 GB)
25. HEAP SIZE DEFAULTS
Non-server class
fo r
Heap setting te
machine (or 32-bit
a s
Windows) or prior to
Server class machine
u p
q p
to J2SE 5.0
e a of
d l 1/64
a e
i4n ev physical
-Xms s MB l (up to 1 GB)
e e
im ris
t p
n r
te te 64 MB 1/4 of physical
f-Xmx
O en (up to 1 GB)
26. FINDING MAX HEAP SIZE
• observe application under consistent load
• then add supplementary 25-30% to peak value
• do not exceed 2 GB value (so say the experts)
29. FINDING INITIAL HEAP SIZE
assign it equal to the max size, and here’s why:
• the heap will grow in the long run anyway
30. FINDING INITIAL HEAP SIZE
assign it equal to the max size, and here’s why:
• the heap will grow in the long run anyway
• baking in the overhead of heap growth/
resizing is viewed as irresponsible by the
experts
31. CAVEATS ON 32-BIT SYSTEMS
• requires contiguous unfragmented chunk of memory
• 32-bit systems may not be able to allocate the desired size
• 2-3 GB per process (Windows)
• 3 GB per process (Linux)
• some amount of memory is eaten up by OS and
background processes
34. APPLICATION CONSIDERATIONS FOR HEAP GENERATIONS SIZES
• reserve plenty of memory for young
generation if creating lots of short-lived
objects
• favor tenured generation if making use
of lots of long-lived objects
37. WHAT ABOUT THAT SURVIVORRATIO FLAG?
Eden S0 S1 Tenured Permanent
38. WHAT ABOUT THAT SURVIVORRATIO FLAG?
• defaults to 1/34 of young generation
• high risk of short-lived objects to migrate to
tenured generation very fast
• best if kept between [1/6; 1/12] of new space
• -XX:SurvivorRatio=6 => 1/8
40. SERIAL COLLECTOR
• suitable only for single processor machines
• relatively efficient
• default on non-server class machines
• -XX:+UseSerialGC
41. SERIAL COLLECTOR
Application GC Application
Threads Stop Threads
42. PARALLEL COLLECTOR
• takes advantage of multiple CPUs/cores
• performs minor collections in parallel
• significantly improves performance in systems
with lots of minor collections
• default on server class machines
• -XX:+UseParallelGC
43. PARALLEL COLLECTOR
• major collections are still single threaded
• -XX:+UseParallelOldGc
• as of J2SE 5.0 update 6
• allows parallel compaction which reduces heap
fragmentation
• allows major collections in parallel
45. CONCURRENT COLLECTOR
• performs most of its work concurrently
• the goal is to keep GC pauses short
• single GC thread that runs
simultaneously with application threads
• -XX:+UseConcMarkSweepGC
46. CONCURRENT COLLECTOR
App App
App Initial Threads + Threads +
Remark
Threads Mark Concurrent Concurrent
Mark Sweep
47. WHICH COLLECTOR WORKS WELL IN MY CASE?
Collector Best for:
Single processor machines + small
Serial heaps
Multiprocessor machines + high
Parallel throughput (batch processing apps)
Fast processor machines + minimized
Concurrent response times (web apps)
51. EXAMPLE
java -verbose:gc -XX:+PrintGCDetails -XX:+PrintHeapAtGC MyApp
18.645: [GC {Heap before GC invocations=16:
Heap
def new generation! total 9088K, used 9088K [0x02a20000, 0x033f0000, 0x05180000)
eden space 8128K, 100% used [0x02a20000, 0x03210000, 0x03210000)
from space 960K, 100% used [0x03210000, 0x03300000, 0x03300000)
to! space 960K,! 0% used [0x03300000, 0x03300000, 0x033f0000)
tenured generation!total 121024K, used 7646K [0x05180000, 0x0c7b0000, 0x22a20000)
the space 121024K,! 6% used [0x05180000, 0x058f7870, 0x058f7a00, 0x0c7b0000)
compacting perm gen total 11264K, used 11202K [0x22a20000, 0x23520000, 0x26a20000)
the space 11264K, 99% used [0x22a20000, 0x23510938, 0x23510a00, 0x23520000)
No shared spaces configured.
52. ANALYSIS TOOLS
• custom scripts
• feed the output to spreadsheet processor & build
charts
• GCViewer - http://www.tagtraum.com/gcviewer.html
• Gchisto - http://java.net/projects/gchisto/
• VisualVM - http://visualvm.java.net
• a host of other tools (commercial & freeware)