GeeCON 2015
First steps in GC tuning
Who am I
• Nikita Salnikov-Tarnovski
• Founder and Master Developer from
• @iNikem / @JavaPlumbr
Agenda
•
•
•
•
•
Why should you care
Bad way to start
Good way to start
Algorithm selection
Region sizing
Garbage Collector
• Subsystem of the
JVM
• Object allocation
and reclamation
Why should I care?
• GC competes for resource with you
• And it always wins
Here is why
GC goes amok
• Application pauses for long time
• GC takes too big share of CPU
Goals of GC tuning
Throughput
Responsiveness
Compactness
Let me tune!
• java -XX:+PrintFlagsFinal
• More than 700 JVM flags
• More than 200 of them are GC related
Where do I start?
•
•
•
•
I will copy flags from previous project
I will look into next department’s project
I will copy suggestions from a blog
I will go to StackOverflow
This is bad way to start
Good way to start
•
•
•
•
•
State your performance goals
Remove all GC related params from your JVM
Run load tests
Measure
Compare to goals
Heap size
•
•
•
•
-XmxNg
GC time depends on live objects
Not total objects or heap size
Usually larger heap is better
GC algorithms
•
•
•
•
•
Totally 8 different in HotSpot
Used in combinations for different heap regions
Roughly speaking Serial, Parallel, CMS and G1
Plus C4 from Azul
Plus Shenandoah
Weak generational hypothesis
• GCs are based on it
• The younger objects
die — the better
(c) Oracle
Object lifecycle
Serial
Serial
•
•
•
•
-XX:+UserSerialGC
Was meant for singe core machines
And heaps of some 100s MBs
But the smallest overhead during run
Parallel
Parallel
•
•
•
•
-XX:+UseParallelGC
a.k.a “Throughput”
Usually, but not always, N times faster than Serial
Occasionally long pauses can occur
ConcurrentMarkSweep
Young
Old
CMS
•
•
•
•
•
•
-XX:+UseConcMarkSweepGC
Parallel in Young, mostly Concurrent in Old
Still STW pauses in both
Not compacting, so Old is fragmenting
The ultimate goal is to collect fast enough
When fails, single threaded Full GC kicks in
G1
• Completely different
layout
• Concurrent and parallel
• Aims to be low pause
replacement for CMS
Copyright © 2012, Oracle and/or its affiliates. All rights reserved.
G1
•
•
•
•
-XX:+UseG1GC
Slowly becoming more popular
Use in jdk8 only, the newer the better
There are plans to make it default in jdk9
Object lifecycle
LiveSet
• The amount of data alive after Major GC
• Should be stable in a healthy application
• For Parallel GC
• -XX:OldSize=LiveSet*(1.2-1.5)
• For CMS GC
• -XX:OldSize=LiveSet*2
Weak generational hypothesis
• GCs are based on it
• The younger objects
die — the better
(c) Oracle
Eden and Survivor
•
•
•
•
Eden>R*T
R - allocation rate of the application
T - time for your objects to die
-XmnNg
External factors
• Other applications and OS
• Can be a source of mysterious long pauses
• Look for high system time in GC logs
Solving performance problems is hard.
We don’t think it needs to be.