A D I G I T A L C O M M E R C E C O N S U LT A N C Y

... because out-of-the-box is often not enough

Basics of JVM Tuning

Vladislav GanganVice President of EngineeringTacit Knowledge, Moldova

• Basics of JVM memory management

• Optimal starting settings for tuning

• Garbage collection algorithms

• Debugging the garbage collection process

• Putting theory in practice

AGENDA

RATIONALE BEHIND THE NEED OF JVM TUNING

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

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

m1 vars

m2 vars

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

m1 vars

free

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

m1 vars

m3 vars

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

m1 vars

m3 vars

m4 vars

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

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

o1

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

o1

o2

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

o1

o2 o3

HEAP STRUCTURE

PermanentTenuredEden S0 S1

GENERATIONAL OBJECT FLOW

GENERATIONAL OBJECT FLOW

GENERATIONAL OBJECT FLOW

GENERATIONAL OBJECT FLOW

GENERATIONAL OBJECT FLOW

Minor collection

GARBAGE COLLECTION ELIGIBILITY

Reachability test - can an object be reached from any live pointer in the application?

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

JVM TUNING PROCESS

while (iAmNotSatis!ed){

size = de!neMinMaxHeapSize();ratios = !neTuneGenerationsRatios();alg = selectAppropriateGcAlgotrithm();loadTestTheApplication(size, ratios, alg);iAmNotSatis!ed = analyzeStatistics();

}

HEAP SIZE CONFIG OPTIONS

-Xms - initial heap size-Xmx - max/!nal heap size

java -Xms123m -Xmx456m MyApp

HEAP SIZE DEFAULTS

Heap setting

Non-server class machine (or 32-bit

Windows) or prior to to J2SE 5.0

Server class machine

-Xms 4 MB1/64 of

physical(up to 1 GB)

-Xmx 64 MB 1/4 of physical(up to 1 GB)

HEAP SIZE DEFAULTS

Heap setting

Non-server class machine (or 32-bit

Windows) or prior to to J2SE 5.0

Server class machine

-Xms 4 MB1/64 of

physical(up to 1 GB)

-Xmx 64 MB 1/4 of physical(up to 1 GB)Oftentimes inadequate for

enterprise level apps

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)

FINDING INITIAL HEAP SIZE

FINDING INITIAL HEAP SIZE

assign it equal to the max size, and here’s why:

FINDING INITIAL HEAP SIZE

assign it equal to the max size, and here’s why:

• the heap will grow in the long run anyway

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

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

WHAT ARE THE OPTIONS?

SIZING HEAP GENERATIONS

-XX:NewSize=123m

-XX:MaxNewSize=123m

-XX:SurvivorRatio=6

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

OPTIMAL SIZE FOR YOUNG GENERATION

[⅓; ½)

WHAT ABOUT THAT SURVIVORRATIO FLAG?

WHAT ABOUT THAT SURVIVORRATIO FLAG?

PermanentTenuredEden S0 S1

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

GARBAGE COLLECTION ALGORITHMS

• serial• parallel• concurrent

SERIAL COLLECTOR

• suitable only for single processor machines

• relatively efficient

• default on non-server class machines

• -XX:+UseSerialGC

SERIAL COLLECTOR

ApplicationThreads

GCStop

ApplicationThreads

PARALLEL COLLECTOR

• takes advantage of multiple CPUs/cores

• performs minor collections in parallel• signi!cantly improves performance in systems with lots of minor collections

• default on server class machines

• -XX:+UseParallelGC

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

PARALLEL COLLECTOR

ApplicationThreads

GCStop

ApplicationThreads

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

CONCURRENT COLLECTOR

AppThreads

AppThreads +Concurrent

Mark

AppThreads +Concurrent

Sweep

RemarkInitialMark

WHICH COLLECTOR WORKS WELL IN MY CASE?

Collector Best for:

Serial Single processor machines + small heaps

Parallel Multiprocessor machines + high throughput (batch processing apps)

Concurrent Fast processor machines + minimized response times (web apps)

GATHERING HEAP BEHAVIOR STATISTICS

• -verbose:gc

• -XX:+PrintGCDetails

• -XX:+PrintHeapAtGC

• -Xloggc:/path/to/gc/log/!le

EXAMPLE

java -verbose:gc MyApp

33.357: [GC 25394K->18238K(130176K), 0.0148471 secs]33.811: [Full GC 22646K->18501K(130176K), 0.1954419 secs]

EXAMPLE

java -verbose:gc -XX:+PrintGCDetails MyApp

19.834: [GC 19.834: [DefNew: 9088K->960K(9088K), 0.0126103 secs] 16709K->9495K(130112K), 0.0126960 secs]20.424: [Full GC 20.424: [Tenured: 8535K->10032K(121024K), 0.1342573 secs] 13847K->10032K(130112K), [Perm : 12287K->12287K(12288K)], 0.1343551 secs]

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.

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)

Let’s practice

RATIONALE BEHIND THE NEED OF JVM TUNING

Q & A

BIBLIOGRAPHY

BIBLIOGRAPHY

BIBLIOGRAPHY

BIBLIOGRAPHY

THANK YOU