SlideShare a Scribd company logo
1 of 71
GC Tuning Confessions
Of A Performance
Engineer
Monica Beckwith
monica@codekaram.com
@mon_beck
www.linkedin.com/in/monicabeckwith
Philly Emerging Tech Conference 2015
April 8th, 2015
©2015 CodeKaram
About Me
• JVM/GC Performance Engineer/Consultant
• Worked at AMD, Sun, Oracle
• Worked with HotSpot JVM
• Worked with Parallel(Old) GC, G1 GC and CMS
GC
2
©2015 CodeKaram
About Today’s Talk
• A little bit about Performance Engineering
• Insight into Garbage Collectors
• Introduction to a few main GC Algorithms in
OpenJDK HotSpot (ParallelOld GC, CMS GC,
and G1 GC)
• Summary
• GC Tunables
3
©2015 CodeKaram
Performance Engineering
• A performance engineer helps ensure that the system is
designed + implemented to meet the performance
requirements.
• The performance requirements could include the
service level agreements (SLAs) for throughput, latency
and other response time related metrics - also known as
non-functional requirements.
• E.g. Response time (RT) metrics - Average (RT), max
or worst-case RT, 99th percentile RT…
• Let’s talk more about these RTs…
4
©2015 CodeKaram
Performance Engineering -
Response Time Metrics
Average (ms) Minimum (ms)
System1 307.741 7.622
System2 320.778 7.258
System3 321.483 6.432
System4 323.143 7.353
5
©2015 CodeKaram
Performance Engineering -
Response Time Metrics
Average (ms)
Number of
GCs
System1 307.741 37353
System2 320.778 34920
System3 321.483 36270
System4 323.143 40636
6
©2015 CodeKaram
Performance Engineering -
Response Time Metrics
Average (ms) Maximum (ms)
System1 307.741 3131.331
System2 320.778 2744.588
System3 321.483 1681.308
System4 323.143 20699.505
7
©2015 CodeKaram
Performance Engineering -
Response Time Metrics
Average (ms) Maximum (ms)
System1 307.741 3131.331
System2 320.778 2744.588
System3 321.483 1681.308
System4 323.143 20699.505
5 full GCs and 10 evacuation failures
8
©2015 CodeKaram
Performance Engineering
• Monitoring, analysis and tuning are a big part of performance
engineering.
• Monitoring utilization - CPU, IO, Memory bandwidth, Java
heap, …
• Analyzing utilization and time spent - GC logs, CPU, memory
and application logs
• Profiling - Application, System, Memory - Java Heap.
• Java/JVM performance engineering includes the study, analysis
and tuning of the Just-in-time (JIT) compiler, the Garbage
Collector (GC) and many a times tuning related to the Java
Development Kit (JDK).
9
©2015 CodeKaram
Insight Into Garbage
Collectors (GCs)
• A GC is an automatic memory management unit.
• An ideal GC is the one that requires minimum footprint
(concurrent CPU or native memory), and provides maximum
throughput while minimizing predictable latency.
• Fun Fact - In reality you will have to tradeoff one (footprint or
latency or throughput) in lieu of the others. A healthy performance
engineering exercise can help you meet or exceed your goals.
• Fun Fact - GC can NOT eliminate your memory leaks!
• Fun Fact - GC (and heap dump) can provide an insight into your
application.
10
©2015 CodeKaram
GC Algorithms in OpenJDK
HotSpot - The Tradeoff
• Throughput and latency are the two main drivers
towards refinement of GC algorithms.
• Fun Fact - Most OpenJDK HotSpot users would
like to increase their (Java) heap space but they
fear full garbage collections.
11
©2015 CodeKaram
GC Algorithms in OpenJDK
HotSpot - Throughput Maximizer
• Throughput has driven us to parallelization of GC worker threads:
• Parallel Collection Threads
• Parallel Concurrent Marking Threads
• Throughput has driven us to generational GCs
• Most objects die young.
• Fast path allocation into “young” generation.
• Age and then promote (fast path again) to “old” generation
• Fun Fact: All GCs in OpenJDK HotSpot are generational.
12
©2015 CodeKaram
GC Algorithms in OpenJDK
HotSpot - Latency Sensitive
• Latency has driven algorithms to no compaction or partial compaction
• Time is of essence, no need to fully compact if free space is still
available!
• Latency has driven algorithms towards concurrency - i.e. running with
the application threads.
• Mostly concurrent mark and sweep (CMS) and concurrent marking
in G1.
• Fun Fact: All GCs in OpenJDK HotSpot fallback to a fully compacting
stop-the-world garbage collection called the “full” GC.
• Tuning can help avoid or postpone full GCs in many cases.
13
©2015 CodeKaram
The Throughput Collector
• ParallelOld is the throughput collector in OpenJDK
HotSpot.
• But, first, what is throughput?
• Throughput is the percentage of time NOT spent in GC :)
• The throughput goal for ParallelOld Collector is 99%.
• That is, all the GC pauses that happen during the life of
the application should account to 1% of the run time.
• How does ParallelOld try to achieve its throughput goal?
14
©2015 CodeKaram
The Throughput Collector -
Java Heap
Eden S0 S1 Old Generation
Young Generation
Allocations
Survivors
Tenured
15
©2015 CodeKaram
• An allocation failure results in a stop-the-world young collection.
• The young generation is collected in its entirety i.e. all objects
(dead or alive) are emptied from the eden and S0 spaces.
• After the young collection is complete, the surviving objects
(objects that are live) are moved into S1.
• Objects are aged in the survivor space until ready for promotion
• When the age threshold is met, objects are promoted into the old
generation.
• Allocations and promotions are both fast tracked (lock-free) by
using Thread/Promotion Local Allocation Buffers (TLAB/PLAB)
The Throughput Collector -
Young Collection
16
©2015 CodeKaram
Old Generation
Free Space
Occupied Space
The Throughput Collector -
Contiguous Old Generation
17
©2015 CodeKaram
Old Generation
To-be Promoted Object 1
The Throughput Collector -
Contiguous Old Generation
18
©2015 CodeKaram
Old Generation
Free Space
Occupied Space
The Throughput Collector -
Contiguous Old Generation
19
©2015 CodeKaram
Old Generation
To-be Promoted Object 2
The Throughput Collector -
Contiguous Old Generation
20
©2015 CodeKaram
Old Generation
Free Space
Occupied Space
The Throughput Collector -
Contiguous Old Generation
21
©2015 CodeKaram
Old Generation
To-be Promoted Object 3
The Throughput Collector -
Contiguous Old Generation
22
©2015 CodeKaram
• When the old generation is full, i.e. when the old generation
can’t accept any promotions, it is time to start a full compaction
collection.
• The ParallelOld collector utilized parallel stop-the-world GC
threads to help compact the entire heap.
• The ParallelOld collector achieves compaction via copying and
moving live data.
• After the end of the full collection, only the compacted live data
set of the java application occupies the old generation. The rest
of the space in the old generation is free for future promotions.
The Throughput Collector -
Contiguous Old Generation
23
©2015 CodeKaram
Young
GC
Threads
Java
Application
Threads
Old GC
Threads
Java
Application
Threads
Java
Application
Threads
The Throughput Collector
24
©2015 CodeKaram
The CMS Collector
• Mostly Concurrent Mark & Sweep collector is geared towards latency sensitive
applications.
• The young collections are pretty similar to what you would observe with
ParallelOld GC’s young collection
• The main difference is in the old generation collection.
• An occupancy threshold determines when the mostly concurrent mark and
sweep cycle can start.
• The sweep cycle just reclaims the dead objects and updates a list of free
spaces. Thus, the CMS collector is not a compacting collector.
• This can lead to fragmentation which can lead to promotion failures
which eventually lead to a fallback single-threaded fully compacting
collection.
25
©2015 CodeKaram
The CMS Collector
• The CMS collector has multiple stop-the-world and concurrent phases -
• After the old generation occupied space reaches or crosses the
occupancy threshold, a CMS cycle is initiated.
• Initially, parallel stop-the-world CMS threads help find the GC roots
to start a live object graph.
• Concurrent CMS threads help in marking further live objects (objects
that are reachable by the roots).
• Parallel stop-the-world CMS threads help in making sure that the
final changes to the graph are duly noted.
• Concurrent sweep phase helps in collecting all dead objects and
updating the free list to track the reclaimed spaces.
26
©2015 CodeKaram
The CMS Collector
Young
GC
Threads
Java
Application
Threads
CMS
Initial
Mark
Threads
Java
Application
Threads
Java
Application
Threads
Young
GC
Threads
CMS
Remark
Threads
Java
Application
Threads
Java
Application
Threads
Concurrent
CMS
Threads
Concurrent
CMS
Threads
Concurrent
CMS
Threads
27
©2015 CodeKaram
The CMS Collector -
Contiguous Old Generation
28
Old Generation
Free List
Free Space
Occupied Space
©2015 CodeKaram
Old Generation
To-be Promoted Object 1
The CMS Collector -
Contiguous Old Generation
29
©2015 CodeKaram
Old Generation
Free List
Free Space
Occupied Space
The CMS Collector -
Contiguous Old Generation
30
©2015 CodeKaram
Old Generation
To-be Promoted Object 2
The CMS Collector -
Contiguous Old Generation
31
©2015 CodeKaram
Old Generation
Free List
Free Space
Occupied Space
The CMS Collector -
Contiguous Old Generation
32
©2015 CodeKaram
X
Old Generation
To-be Promoted Object 3
The CMS Collector -
Contiguous Old Generation
33
©2015 CodeKaram
X
Old Generation
To-be Promoted Object 3
The CMS Collector -
Contiguous Old Generation
34
©2015 CodeKaram
X
Old Generation
To-be Promoted Object 3
The CMS Collector -
Contiguous Old Generation
35
©2015 CodeKaram
X
Old Generation
To-be Promoted Object 3
The CMS Collector -
Contiguous Old Generation
36
©2015 CodeKaram
Old Generation
To-be Promoted Object 3
??
The CMS Collector -
Contiguous Old Generation
37
©2015 CodeKaram
Old Generation
To-be Promoted Object 3
Promotion Failure!!
The CMS Collector -
Contiguous Old Generation
38
©2015 CodeKaram
• When CMS just can’t keep up with the promotion
rate
• Your old generation is getting filled before a
concurrent cycle can free up space and
complete.
• Causes - marking threshold is too high, heap too
small, or high application mutation rate
39
The CMS Collector -
Concurrent Mode Failures
©2015 CodeKaram
The Garbage First Collector
• Garbage First (G1) is the newest collector in OpenJDK HotSpot.
• G1 GC is supposed to be a long term replacement of CMS GC.
• G1 GC introduces the concept of regionalized heap.
• The idea is to set a pause time goal which will be used as a hint
by the ergonomics and prediction logic and G1 GC will try to
adjust its generations and number of regions per collections so
as to best meet its pause time goal.
• G1 has multi-staged concurrent marking phase as well as stop
the world collections for young and old generations
40
©2015 CodeKaram
The Garbage First Collector
• Throughput is a secondary consideration for G1. Hence the throughput
goal is to have about 10% of the total time be spent in GC activities.
• G1 GC aims to provide more predictable pause times.
• The G1 GC regionalized heap ensures that the generations don’t have
to be contiguous (as they were in ParallelOld and CMS GCs).
• With regions, G1 just needs to know the limits for each generation and
the pause time goal.
• G1 will add regions as needed from the list of free regions.
• Occupied regions can be eden, survivor, old and humongous (more
on this later).
41
©2015 CodeKaram
The Garbage First Collector
- Regionalized Heap
Eden
Old Old
Eden
Old
Survivor
Humongous
42
©2015 CodeKaram
• For G1 GC, the young generation consists of eden regions and survivor
regions.
• A region is a unit of collection
• The region size is determined at JVM startup (and can be changed if
needed)
• Most allocations are fast path allocations into the eden regions.
• The survivor regions help in aging the objects which are eventually
promoted into the old generation after the age threshold is crossed
• The young generation is resized after every collection based on the
time it took the current collection, the pause time goal and other factors
considered by the prediction logic.
The Garbage First Collector
- The Young Generation
43
©2015 CodeKaram
The Garbage First Collector
Eden
Old Old
Eden
Old
Surv
ivor
E.g.: Current heap configuration -
44
©2015 CodeKaram
The Garbage First Collector
Eden
Old Old
Eden
Old
Surv
ivor
E.g.: During a young collection -
45
©2015 CodeKaram
The Garbage First Collector
Old Old
Old
E.g.: After a young collection -
Sur
vivor
Old
46
©2015 CodeKaram
• For G1 GC, the old generation collection consists of all of the
young regions and a few candidate old regions. Such a
collection is called a mixed collection.
• The GC ergonomics selects the candidate old regions based
on certain thresholds and calculations that help determine
the regions with the most reclaimable space and at the same
time giving consideration to the pause time goal.
• Based on the total number of candidate old regions, the pause
time goal and other collection related thresholds, you could see
more that one mixed collection pause. Thus the old generation
is collected incrementally.
The Garbage First Collector
- The Old Generation
47
©2015 CodeKaram
• In-order to start a mixed collection, the heap occupancy
threshold (also known as the marking threshold) must be
crossed.
• When the marking threshold is crossed, G1 GC initiates
a concurrent marking cycle. The concurrent cycle is
mostly concurrent, except for when marking the roots
and when remarking to make sure all the mutations are
captured appropriately in the object graph.
• During the concurrent marking phase, any garbage-filled
regions are reclaimed as a part of the cleanup phase.
The Garbage First Collector
- The Marking Threshold
48
©2015 CodeKaram
The Garbage First Collector
Old Old
Old
E.g.: Current heap configuration -
Sur
vivor
Old
Eden Eden
Old
49
©2015 CodeKaram
Old Old
Old
E.g.: Reclamation of a garbage-filled region during a
concurrent cleanup phase -
Sur
vivor
Old
Eden Eden
Old
The Garbage First Collector
50
©2015 CodeKaram
Old Old
Old
E.g.: Current heap configuration -
Sur
vivor
Old
Eden Eden
The Garbage First Collector
51
©2015 CodeKaram
Old Old
Old
E.g.: During a mixed collection -
Sur
vivor
Old
Eden Eden
The Garbage First Collector
52
©2015 CodeKaram
Old
E.g.: After a mixed collection -
O
ld
Surv
ivor
Old
The Garbage First Collector
53
©2015 CodeKaram
• Objects >= 50% of G1 region size == Humongous Objects
• These objects are allocated directly into the old generation into
Humongous Regions
• If a humongous object is bigger than a G1 region, then the
humongous regions that contain it have to be contiguous.
• Ideally, humongous objects are few in number and are short
lived.
• Can cause evacuation failures if application allocates a lot
of long-lived humongous objects, since humongous
regions add to the old generation occupancy.
The Garbage First Collector
- Humongous Objects
54
©2015 CodeKaram
• Evacuation failures or promotion failures or to-
space overflow or exhausted all refer to the same
notion.
• When there are no more regions available for
survivors or tenured objects, G1 GC encounters
an evacuation failure.
• An evacuation failure is expensive and the usual
pattern is that if you see a couple of evacuation
failures; full GC will soon follow.
The Garbage First Collector
- Evacuation Failures
55
©2015 CodeKaram
• Make sure your command line is not overloaded - Avoid over-
tuning!
• Try increasing your heap size.
• Check if humongous allocations are the cause of your problem.
• Adjust the marking threshold
• Try increasing your concurrent threads to help reduce the time
for concurrent marking phase.
• If survivor objects are the issue, try increase the
G1ReservePercent
The Garbage First Collector -
Avoiding Evacuation Failures
56
©2015 CodeKaram
What have we learned so far? -
Young Generation & Collections
• Young generation is always collected in its entirety.
• All 3 GCs discussed earlier follow similar mechanism
for young collection.
• The young collections achieve reclamation via
compaction and copying of live objects.
• There are a lot of options for sizing the Eden and
Survivor space optimally and many GCs also have
adaptive sizing and ergonomics for young generation
collections.
57
©2015 CodeKaram
Most Allocations Eden Space
Eden Full? Start Young Collection: Keep Allocating :)
Objects Aged in Survivor Space? Promote: Keep Aging :)
Fast Path
Promotions
Fast Path
Old Generation
CMS promotes to fitting free space out of a free list.
What have we learned so far? -
Young Generation & Collections
58
©2015 CodeKaram
All 3 GCs vary in the way they collect the old generation:
• For ParallelOld GC, the old generation is reclaimed and
compacted in its entirety
• Luckily, the compaction cost is distributed amongst parallel
garbage collector worker threads.
• Unluckily, the compaction cost depends a lot on the size of
the live data set since at every compaction, the GC is moving
live data around.
• No tuning options other than the generation size adjustment
and age threshold for promotion.
59
What have we learned so far?
- Old Generation & Collections
©2015 CodeKaram
• For CMS GC, the old generation is (mostly) concurrently marked
and swept. Thus the reclamation of dead objects happen in place
and the space is added to a free list of spaces.
• The marking threshold can be tuned adaptively and manually as
well.
• Luckily, CMS GC doesn’t do compaction, hence reclamation is fast.
• Unluckily, a long running Java application with CMS GC is prone to
fragmentation which will eventually result in promotion failures
which can eventually lead to full compacting garbage collection
and sometimes even concurrent mode failures.
• Full compacting GCs are singled threaded in CMS GC.
What have we learned so far?
- Old Generation & Collections
60
©2015 CodeKaram
• For G1 GC, the old generation regions are (mostly) concurrently marked and
an incremental compacting collection helps with optimizing the old generation
collection.
• Luckily, fragmentation is not “untunable” in G1 GC as it is in CMS GC.
• Unluckily, sometimes, you may still encounter promotion/evacuation failures
when G1 GC runs out of regions to copy live objects. Such an evacuation
failure is expensive and can eventually lead to a full compacting GC.
• Full compacting GCs are singled threaded in G1 GC.
• Appropriate tuning of the old generation space and collection can help
avoid evacuation failures and hence keep full GCs at bay.
• G1 GC has multiple tuning options so that the GC can be adapted to your
application needs.
61
What have we learned so far?
- Old Generation & Collections
©2015 CodeKaram
GC Tunables - The
Throughput Collector
Goal:
Only promote objects after you have hazed
them appropriately
aged
Tunables:
Everything related to aging objects and
generation sizing -
NewRatio, (Max)NewSize, SurvivorRatio,
(Max)TenuringThreshold
62
©2015 CodeKaram
GC Tunables - The
Throughput Collector
Things to remember -
• Applications with steady behavior rarely need
AdaptiveSizePolicy to be enabled.
• Overflow gets promoted into the old generation
• Provide larger survivor spaces for long-lived transient data.
• In most cases, young generation sizing has the most effect
on throughput
• Size the young generation to maintain the GC overhead to
less than 5%.
63
©2015 CodeKaram
GC Tunables - The CMS
Collector
Goal:
Only promote objects after you have hazed
them appropriately
aged
Tunables:
Everything related to aging objects and young
generation sizing still applies here.
The concurrent thread counts and marking
threshold are addition tunables for CMS
64
©2015 CodeKaram
GC Tunables - The CMS
Collector
Things to remember -
• Premature promotions are very expensive in CMS and could lead to
fragmentation
• You can reduce the CMS cycle duration by adding more concurrent
threads: ConcGCThreads.
• Remember that this will increase the concurrent overhead.
• You can manually tune the marking threshold (adaptive by default)
• CMSInitiatingOccupancyFraction & UseCMSInitiatingOccupancyOnly
will help fix the marking threshold.
• Note: The threshold is expressed as a percentage of the old generation
occupancy
65
©2015 CodeKaram
GC Tunables - The G1
Collector
Goal:
Get the ergonomics to work for you and
know the defaults
Tunables:
• Pause time goal, heap size, max and min
nursery, concurrent and parallel threads
• The marking threshold, number of mixed GCs
after marking, liveness threshold for the old
regions, garbage toleration threshold, max old
regions to be collected per mixed collection
66
©2015 CodeKaram
GC Tunables - The G1
Collector
Things to remember -
• Know your defaults!
• Understand your G1HeapRegionSize - It could be any factor of
two from 1MB to 32MB. G1 strives for 2048 regions.
• Fixing the nursery size (using Xmn) will meddle with the GC
ergonomics.
• Don’t set really aggressive pause time goals - this will increase the
GC overhead.
• Spend time taming your mixed GCs - mixed GCs are incremental
old generation collections
67
©2015 CodeKaram
GC Tunables - The G1
Collector
Things to remember -
• Taming mixed GCs:
• Adjust the marking cycle according to you live data set.
• Adjust you liveness threshold - this is the live occupancy threshold
per region. Any region with liveness beyond this threshold will not
be included in a mixed collection.
• Adjust your garbage toleration threshold - helps G1 not get too
aggressive with mixed collections
• Distribute mixed GC pauses over a number of mixed collections -
adjust your mixed GC count target and change your max old region
threshold percent so that you can limit the old regions per collection
68
©2015 CodeKaram
Further Reading
69
©2015 CodeKaram
Further Reading
70
©2015 CodeKaram
Further Reading
• Jon Masa’s blog: https://blogs.oracle.com/
jonthecollector/entry/our_collectors
• A few of my articles on InfoQ: http://
www.infoq.com/author/Monica-Beckwith
• Presentations: http://www.slideshare.net/
MonicaBeckwith
• Mail archives on hotspot-gc-use@openjdk.java.net
& hotspot-gc-dev@openjdk.java.net
71

More Related Content

What's hot

G1 collector and tuning and Cassandra
G1 collector and tuning and CassandraG1 collector and tuning and Cassandra
G1 collector and tuning and CassandraChris Lohfink
 
OPENJDK: IN THE NEW AGE OF CONCURRENT GARBAGE COLLECTORS
OPENJDK: IN THE NEW AGE OF CONCURRENT GARBAGE COLLECTORSOPENJDK: IN THE NEW AGE OF CONCURRENT GARBAGE COLLECTORS
OPENJDK: IN THE NEW AGE OF CONCURRENT GARBAGE COLLECTORSMonica Beckwith
 
Java Performance Engineer's Survival Guide
Java Performance Engineer's Survival GuideJava Performance Engineer's Survival Guide
Java Performance Engineer's Survival GuideMonica Beckwith
 
JFokus Java 9 contended locking performance
JFokus Java 9 contended locking performanceJFokus Java 9 contended locking performance
JFokus Java 9 contended locking performanceMonica Beckwith
 
Garbage First Garbage Collector (G1 GC) - Migration to, Expectations and Adva...
Garbage First Garbage Collector (G1 GC) - Migration to, Expectations and Adva...Garbage First Garbage Collector (G1 GC) - Migration to, Expectations and Adva...
Garbage First Garbage Collector (G1 GC) - Migration to, Expectations and Adva...Monica Beckwith
 
Java Garbage Collectors – Moving to Java7 Garbage First (G1) Collector
Java Garbage Collectors – Moving to Java7 Garbage First (G1) CollectorJava Garbage Collectors – Moving to Java7 Garbage First (G1) Collector
Java Garbage Collectors – Moving to Java7 Garbage First (G1) CollectorGurpreet Sachdeva
 
G1 Garbage Collector - Big Heaps and Low Pauses?
G1 Garbage Collector - Big Heaps and Low Pauses?G1 Garbage Collector - Big Heaps and Low Pauses?
G1 Garbage Collector - Big Heaps and Low Pauses?C2B2 Consulting
 
Enabling Java: Windows on Arm64 - A Success Story!
Enabling Java: Windows on Arm64 - A Success Story!Enabling Java: Windows on Arm64 - A Success Story!
Enabling Java: Windows on Arm64 - A Success Story!Monica Beckwith
 
Moving to g1 gc by Kirk Pepperdine.
Moving to g1 gc by Kirk Pepperdine.Moving to g1 gc by Kirk Pepperdine.
Moving to g1 gc by Kirk Pepperdine.J On The Beach
 
Storing Cassandra Metrics
Storing Cassandra MetricsStoring Cassandra Metrics
Storing Cassandra MetricsChris Lohfink
 
Hadoop world g1_gc_forh_base_v4
Hadoop world g1_gc_forh_base_v4Hadoop world g1_gc_forh_base_v4
Hadoop world g1_gc_forh_base_v4YanpingWang
 
Tuning Java for Big Data
Tuning Java for Big DataTuning Java for Big Data
Tuning Java for Big DataScott Seighman
 
Performance tuning jvm
Performance tuning jvmPerformance tuning jvm
Performance tuning jvmPrem Kuppumani
 
JVM memory management & Diagnostics
JVM memory management & DiagnosticsJVM memory management & Diagnostics
JVM memory management & DiagnosticsDhaval Shah
 
Jvm Performance Tunning
Jvm Performance TunningJvm Performance Tunning
Jvm Performance Tunningguest1f2740
 
Garbage First and you
Garbage First and youGarbage First and you
Garbage First and youKai Koenig
 

What's hot (20)

G1 collector and tuning and Cassandra
G1 collector and tuning and CassandraG1 collector and tuning and Cassandra
G1 collector and tuning and Cassandra
 
OPENJDK: IN THE NEW AGE OF CONCURRENT GARBAGE COLLECTORS
OPENJDK: IN THE NEW AGE OF CONCURRENT GARBAGE COLLECTORSOPENJDK: IN THE NEW AGE OF CONCURRENT GARBAGE COLLECTORS
OPENJDK: IN THE NEW AGE OF CONCURRENT GARBAGE COLLECTORS
 
Java Performance Engineer's Survival Guide
Java Performance Engineer's Survival GuideJava Performance Engineer's Survival Guide
Java Performance Engineer's Survival Guide
 
JFokus Java 9 contended locking performance
JFokus Java 9 contended locking performanceJFokus Java 9 contended locking performance
JFokus Java 9 contended locking performance
 
Garbage First Garbage Collector (G1 GC) - Migration to, Expectations and Adva...
Garbage First Garbage Collector (G1 GC) - Migration to, Expectations and Adva...Garbage First Garbage Collector (G1 GC) - Migration to, Expectations and Adva...
Garbage First Garbage Collector (G1 GC) - Migration to, Expectations and Adva...
 
Java Garbage Collectors – Moving to Java7 Garbage First (G1) Collector
Java Garbage Collectors – Moving to Java7 Garbage First (G1) CollectorJava Garbage Collectors – Moving to Java7 Garbage First (G1) Collector
Java Garbage Collectors – Moving to Java7 Garbage First (G1) Collector
 
G1 Garbage Collector - Big Heaps and Low Pauses?
G1 Garbage Collector - Big Heaps and Low Pauses?G1 Garbage Collector - Big Heaps and Low Pauses?
G1 Garbage Collector - Big Heaps and Low Pauses?
 
Enabling Java: Windows on Arm64 - A Success Story!
Enabling Java: Windows on Arm64 - A Success Story!Enabling Java: Windows on Arm64 - A Success Story!
Enabling Java: Windows on Arm64 - A Success Story!
 
Moving to g1 gc by Kirk Pepperdine.
Moving to g1 gc by Kirk Pepperdine.Moving to g1 gc by Kirk Pepperdine.
Moving to g1 gc by Kirk Pepperdine.
 
Storing Cassandra Metrics
Storing Cassandra MetricsStoring Cassandra Metrics
Storing Cassandra Metrics
 
-XX:+UseG1GC
-XX:+UseG1GC-XX:+UseG1GC
-XX:+UseG1GC
 
Hadoop world g1_gc_forh_base_v4
Hadoop world g1_gc_forh_base_v4Hadoop world g1_gc_forh_base_v4
Hadoop world g1_gc_forh_base_v4
 
G1GC
G1GCG1GC
G1GC
 
Tuning Java for Big Data
Tuning Java for Big DataTuning Java for Big Data
Tuning Java for Big Data
 
Performance tuning jvm
Performance tuning jvmPerformance tuning jvm
Performance tuning jvm
 
Moving to G1GC
Moving to G1GCMoving to G1GC
Moving to G1GC
 
JVM memory management & Diagnostics
JVM memory management & DiagnosticsJVM memory management & Diagnostics
JVM memory management & Diagnostics
 
Jvm Performance Tunning
Jvm Performance TunningJvm Performance Tunning
Jvm Performance Tunning
 
Garbage First and you
Garbage First and youGarbage First and you
Garbage First and you
 
Trouble with memory
Trouble with memoryTrouble with memory
Trouble with memory
 

Similar to GC Tuning Confessions Of A Performance Engineer

JVM Performance Tuning
JVM Performance TuningJVM Performance Tuning
JVM Performance TuningJeremy Leisy
 
Choosing Right Garbage Collector to Increase Efficiency of Java Memory Usage
Choosing Right Garbage Collector to Increase Efficiency of Java Memory UsageChoosing Right Garbage Collector to Increase Efficiency of Java Memory Usage
Choosing Right Garbage Collector to Increase Efficiency of Java Memory UsageJelastic Multi-Cloud PaaS
 
this-is-garbage-talk-2022.pptx
this-is-garbage-talk-2022.pptxthis-is-garbage-talk-2022.pptx
this-is-garbage-talk-2022.pptxTier1 app
 
millions-gc-jax-2022.pptx
millions-gc-jax-2022.pptxmillions-gc-jax-2022.pptx
millions-gc-jax-2022.pptxTier1 app
 
Elastic JVM for Scalable Java EE Applications Running in Containers #Jakart...
Elastic JVM  for Scalable Java EE Applications  Running in Containers #Jakart...Elastic JVM  for Scalable Java EE Applications  Running in Containers #Jakart...
Elastic JVM for Scalable Java EE Applications Running in Containers #Jakart...Jelastic Multi-Cloud PaaS
 
Вячеслав Блинов «Java Garbage Collection: A Performance Impact»
Вячеслав Блинов «Java Garbage Collection: A Performance Impact»Вячеслав Блинов «Java Garbage Collection: A Performance Impact»
Вячеслав Блинов «Java Garbage Collection: A Performance Impact»Anna Shymchenko
 
淺談 Java GC 原理、調教和 新發展
淺談 Java GC 原理、調教和新發展淺談 Java GC 原理、調教和新發展
淺談 Java GC 原理、調教和 新發展Leon Chen
 
How to Become a Winner in the JVM Performance-Tuning Battle
How to Become a Winner in the JVM Performance-Tuning BattleHow to Become a Winner in the JVM Performance-Tuning Battle
How to Become a Winner in the JVM Performance-Tuning BattleCapgemini
 
Taming GC Pauses for Humongous Java Heaps in Spark Graph Computing-(Eric Kacz...
Taming GC Pauses for Humongous Java Heaps in Spark Graph Computing-(Eric Kacz...Taming GC Pauses for Humongous Java Heaps in Spark Graph Computing-(Eric Kacz...
Taming GC Pauses for Humongous Java Heaps in Spark Graph Computing-(Eric Kacz...Spark Summit
 
State of Java Elasticity. Tuning Java Efficiency - GIDS.JAVA LIVE 2020
State of Java Elasticity. Tuning Java Efficiency - GIDS.JAVA LIVE 2020State of Java Elasticity. Tuning Java Efficiency - GIDS.JAVA LIVE 2020
State of Java Elasticity. Tuning Java Efficiency - GIDS.JAVA LIVE 2020Jelastic Multi-Cloud PaaS
 
Better Kafka Performance Without Changing Any Code | Simon Ritter, Azul
Better Kafka Performance Without Changing Any Code | Simon Ritter, AzulBetter Kafka Performance Without Changing Any Code | Simon Ritter, Azul
Better Kafka Performance Without Changing Any Code | Simon Ritter, AzulHostedbyConfluent
 
Better Kafka Performance Without Changing Any Code | Simon Ritter, Azul
Better Kafka Performance Without Changing Any Code | Simon Ritter, AzulBetter Kafka Performance Without Changing Any Code | Simon Ritter, Azul
Better Kafka Performance Without Changing Any Code | Simon Ritter, AzulHostedbyConfluent
 
Jvm problem diagnostics
Jvm problem diagnosticsJvm problem diagnostics
Jvm problem diagnosticsDanijel Mitar
 
Software Profiling: Java Performance, Profiling and Flamegraphs
Software Profiling: Java Performance, Profiling and FlamegraphsSoftware Profiling: Java Performance, Profiling and Flamegraphs
Software Profiling: Java Performance, Profiling and FlamegraphsIsuru Perera
 
Java at Scale, Dallas JUG, October 2013
Java at Scale, Dallas JUG, October 2013Java at Scale, Dallas JUG, October 2013
Java at Scale, Dallas JUG, October 2013Azul Systems Inc.
 
Kubecon seattle 2018 workshop slides
Kubecon seattle 2018 workshop slidesKubecon seattle 2018 workshop slides
Kubecon seattle 2018 workshop slidesWeaveworks
 
Secrets of Performance Tuning Java on Kubernetes
Secrets of Performance Tuning Java on KubernetesSecrets of Performance Tuning Java on Kubernetes
Secrets of Performance Tuning Java on KubernetesBruno Borges
 

Similar to GC Tuning Confessions Of A Performance Engineer (20)

ZGC-SnowOne.pdf
ZGC-SnowOne.pdfZGC-SnowOne.pdf
ZGC-SnowOne.pdf
 
JVM Performance Tuning
JVM Performance TuningJVM Performance Tuning
JVM Performance Tuning
 
Choosing Right Garbage Collector to Increase Efficiency of Java Memory Usage
Choosing Right Garbage Collector to Increase Efficiency of Java Memory UsageChoosing Right Garbage Collector to Increase Efficiency of Java Memory Usage
Choosing Right Garbage Collector to Increase Efficiency of Java Memory Usage
 
this-is-garbage-talk-2022.pptx
this-is-garbage-talk-2022.pptxthis-is-garbage-talk-2022.pptx
this-is-garbage-talk-2022.pptx
 
millions-gc-jax-2022.pptx
millions-gc-jax-2022.pptxmillions-gc-jax-2022.pptx
millions-gc-jax-2022.pptx
 
Java Performance Tuning
Java Performance TuningJava Performance Tuning
Java Performance Tuning
 
Elastic JVM for Scalable Java EE Applications Running in Containers #Jakart...
Elastic JVM  for Scalable Java EE Applications  Running in Containers #Jakart...Elastic JVM  for Scalable Java EE Applications  Running in Containers #Jakart...
Elastic JVM for Scalable Java EE Applications Running in Containers #Jakart...
 
Вячеслав Блинов «Java Garbage Collection: A Performance Impact»
Вячеслав Блинов «Java Garbage Collection: A Performance Impact»Вячеслав Блинов «Java Garbage Collection: A Performance Impact»
Вячеслав Блинов «Java Garbage Collection: A Performance Impact»
 
淺談 Java GC 原理、調教和 新發展
淺談 Java GC 原理、調教和新發展淺談 Java GC 原理、調教和新發展
淺談 Java GC 原理、調教和 新發展
 
How to Become a Winner in the JVM Performance-Tuning Battle
How to Become a Winner in the JVM Performance-Tuning BattleHow to Become a Winner in the JVM Performance-Tuning Battle
How to Become a Winner in the JVM Performance-Tuning Battle
 
Taming GC Pauses for Humongous Java Heaps in Spark Graph Computing-(Eric Kacz...
Taming GC Pauses for Humongous Java Heaps in Spark Graph Computing-(Eric Kacz...Taming GC Pauses for Humongous Java Heaps in Spark Graph Computing-(Eric Kacz...
Taming GC Pauses for Humongous Java Heaps in Spark Graph Computing-(Eric Kacz...
 
State of Java Elasticity. Tuning Java Efficiency - GIDS.JAVA LIVE 2020
State of Java Elasticity. Tuning Java Efficiency - GIDS.JAVA LIVE 2020State of Java Elasticity. Tuning Java Efficiency - GIDS.JAVA LIVE 2020
State of Java Elasticity. Tuning Java Efficiency - GIDS.JAVA LIVE 2020
 
Værktøjer udviklet på AAU til analyse af SCJ programmer
Værktøjer udviklet på AAU til analyse af SCJ programmerVærktøjer udviklet på AAU til analyse af SCJ programmer
Værktøjer udviklet på AAU til analyse af SCJ programmer
 
Better Kafka Performance Without Changing Any Code | Simon Ritter, Azul
Better Kafka Performance Without Changing Any Code | Simon Ritter, AzulBetter Kafka Performance Without Changing Any Code | Simon Ritter, Azul
Better Kafka Performance Without Changing Any Code | Simon Ritter, Azul
 
Better Kafka Performance Without Changing Any Code | Simon Ritter, Azul
Better Kafka Performance Without Changing Any Code | Simon Ritter, AzulBetter Kafka Performance Without Changing Any Code | Simon Ritter, Azul
Better Kafka Performance Without Changing Any Code | Simon Ritter, Azul
 
Jvm problem diagnostics
Jvm problem diagnosticsJvm problem diagnostics
Jvm problem diagnostics
 
Software Profiling: Java Performance, Profiling and Flamegraphs
Software Profiling: Java Performance, Profiling and FlamegraphsSoftware Profiling: Java Performance, Profiling and Flamegraphs
Software Profiling: Java Performance, Profiling and Flamegraphs
 
Java at Scale, Dallas JUG, October 2013
Java at Scale, Dallas JUG, October 2013Java at Scale, Dallas JUG, October 2013
Java at Scale, Dallas JUG, October 2013
 
Kubecon seattle 2018 workshop slides
Kubecon seattle 2018 workshop slidesKubecon seattle 2018 workshop slides
Kubecon seattle 2018 workshop slides
 
Secrets of Performance Tuning Java on Kubernetes
Secrets of Performance Tuning Java on KubernetesSecrets of Performance Tuning Java on Kubernetes
Secrets of Performance Tuning Java on Kubernetes
 

More from Monica Beckwith

The ilities of software engineering.pptx
The ilities of software engineering.pptxThe ilities of software engineering.pptx
The ilities of software engineering.pptxMonica Beckwith
 
Applying Concurrency Cookbook Recipes to SPEC JBB
Applying Concurrency Cookbook Recipes to SPEC JBBApplying Concurrency Cookbook Recipes to SPEC JBB
Applying Concurrency Cookbook Recipes to SPEC JBBMonica Beckwith
 
Intro to Garbage Collection
Intro to Garbage CollectionIntro to Garbage Collection
Intro to Garbage CollectionMonica Beckwith
 
OpenJDK Concurrent Collectors
OpenJDK Concurrent CollectorsOpenJDK Concurrent Collectors
OpenJDK Concurrent CollectorsMonica Beckwith
 
Java 9: The (G1) GC Awakens!
Java 9: The (G1) GC Awakens!Java 9: The (G1) GC Awakens!
Java 9: The (G1) GC Awakens!Monica Beckwith
 

More from Monica Beckwith (7)

The ilities of software engineering.pptx
The ilities of software engineering.pptxThe ilities of software engineering.pptx
The ilities of software engineering.pptx
 
A G1GC Saga-KCJUG.pptx
A G1GC Saga-KCJUG.pptxA G1GC Saga-KCJUG.pptx
A G1GC Saga-KCJUG.pptx
 
QCon London.pdf
QCon London.pdfQCon London.pdf
QCon London.pdf
 
Applying Concurrency Cookbook Recipes to SPEC JBB
Applying Concurrency Cookbook Recipes to SPEC JBBApplying Concurrency Cookbook Recipes to SPEC JBB
Applying Concurrency Cookbook Recipes to SPEC JBB
 
Intro to Garbage Collection
Intro to Garbage CollectionIntro to Garbage Collection
Intro to Garbage Collection
 
OpenJDK Concurrent Collectors
OpenJDK Concurrent CollectorsOpenJDK Concurrent Collectors
OpenJDK Concurrent Collectors
 
Java 9: The (G1) GC Awakens!
Java 9: The (G1) GC Awakens!Java 9: The (G1) GC Awakens!
Java 9: The (G1) GC Awakens!
 

Recently uploaded

Microsoft365_Dev_Security_2024_05_16.pdf
Microsoft365_Dev_Security_2024_05_16.pdfMicrosoft365_Dev_Security_2024_05_16.pdf
Microsoft365_Dev_Security_2024_05_16.pdfMarkus Moeller
 
Team Transformation Tactics for Holistic Testing and Quality (NewCrafts Paris...
Team Transformation Tactics for Holistic Testing and Quality (NewCrafts Paris...Team Transformation Tactics for Holistic Testing and Quality (NewCrafts Paris...
Team Transformation Tactics for Holistic Testing and Quality (NewCrafts Paris...Lisi Hocke
 
UNI DI NAPOLI FEDERICO II - Il ruolo dei grafi nell'AI Conversazionale Ibrida
UNI DI NAPOLI FEDERICO II - Il ruolo dei grafi nell'AI Conversazionale IbridaUNI DI NAPOLI FEDERICO II - Il ruolo dei grafi nell'AI Conversazionale Ibrida
UNI DI NAPOLI FEDERICO II - Il ruolo dei grafi nell'AI Conversazionale IbridaNeo4j
 
GraphSummit Milan - Neo4j: The Art of the Possible with Graph
GraphSummit Milan - Neo4j: The Art of the Possible with GraphGraphSummit Milan - Neo4j: The Art of the Possible with Graph
GraphSummit Milan - Neo4j: The Art of the Possible with GraphNeo4j
 
GraphSummit Milan - Visione e roadmap del prodotto Neo4j
GraphSummit Milan - Visione e roadmap del prodotto Neo4jGraphSummit Milan - Visione e roadmap del prodotto Neo4j
GraphSummit Milan - Visione e roadmap del prodotto Neo4jNeo4j
 
CERVED e Neo4j su una nuvola, migrazione ed evoluzione di un grafo mission cr...
CERVED e Neo4j su una nuvola, migrazione ed evoluzione di un grafo mission cr...CERVED e Neo4j su una nuvola, migrazione ed evoluzione di un grafo mission cr...
CERVED e Neo4j su una nuvola, migrazione ed evoluzione di un grafo mission cr...Neo4j
 
BusinessGPT - Security and Governance for Generative AI
BusinessGPT  - Security and Governance for Generative AIBusinessGPT  - Security and Governance for Generative AI
BusinessGPT - Security and Governance for Generative AIAGATSoftware
 
Encryption Recap: A Refresher on Key Concepts
Encryption Recap: A Refresher on Key ConceptsEncryption Recap: A Refresher on Key Concepts
Encryption Recap: A Refresher on Key Conceptsthomashtkim
 
Evolving Data Governance for the Real-time Streaming and AI Era
Evolving Data Governance for the Real-time Streaming and AI EraEvolving Data Governance for the Real-time Streaming and AI Era
Evolving Data Governance for the Real-time Streaming and AI Eraconfluent
 
Transformer Neural Network Use Cases with Links
Transformer Neural Network Use Cases with LinksTransformer Neural Network Use Cases with Links
Transformer Neural Network Use Cases with LinksJinanKordab
 
Modern binary build systems - PyCon 2024
Modern binary build systems - PyCon 2024Modern binary build systems - PyCon 2024
Modern binary build systems - PyCon 2024Henry Schreiner
 
[GeeCON2024] How I learned to stop worrying and love the dark silicon apocalypse
[GeeCON2024] How I learned to stop worrying and love the dark silicon apocalypse[GeeCON2024] How I learned to stop worrying and love the dark silicon apocalypse
[GeeCON2024] How I learned to stop worrying and love the dark silicon apocalypseTomasz Kowalczewski
 
OpenChain Webinar: AboutCode and Beyond - End-to-End SCA
OpenChain Webinar: AboutCode and Beyond - End-to-End SCAOpenChain Webinar: AboutCode and Beyond - End-to-End SCA
OpenChain Webinar: AboutCode and Beyond - End-to-End SCAShane Coughlan
 
The mythical technical debt. (Brooke, please, forgive me)
The mythical technical debt. (Brooke, please, forgive me)The mythical technical debt. (Brooke, please, forgive me)
The mythical technical debt. (Brooke, please, forgive me)Roberto Bettazzoni
 
[GRCPP] Introduction to concepts (C++20)
[GRCPP] Introduction to concepts (C++20)[GRCPP] Introduction to concepts (C++20)
[GRCPP] Introduction to concepts (C++20)Dimitrios Platis
 
From Theory to Practice: Utilizing SpiraPlan's REST API
From Theory to Practice: Utilizing SpiraPlan's REST APIFrom Theory to Practice: Utilizing SpiraPlan's REST API
From Theory to Practice: Utilizing SpiraPlan's REST APIInflectra
 
Workshop - Architecting Innovative Graph Applications- GraphSummit Milan
Workshop -  Architecting Innovative Graph Applications- GraphSummit MilanWorkshop -  Architecting Innovative Graph Applications- GraphSummit Milan
Workshop - Architecting Innovative Graph Applications- GraphSummit MilanNeo4j
 

Recently uploaded (20)

Abortion Pill Prices Jozini ](+27832195400*)[ 🏥 Women's Abortion Clinic in Jo...
Abortion Pill Prices Jozini ](+27832195400*)[ 🏥 Women's Abortion Clinic in Jo...Abortion Pill Prices Jozini ](+27832195400*)[ 🏥 Women's Abortion Clinic in Jo...
Abortion Pill Prices Jozini ](+27832195400*)[ 🏥 Women's Abortion Clinic in Jo...
 
Microsoft365_Dev_Security_2024_05_16.pdf
Microsoft365_Dev_Security_2024_05_16.pdfMicrosoft365_Dev_Security_2024_05_16.pdf
Microsoft365_Dev_Security_2024_05_16.pdf
 
Abortion Clinic In Stanger ](+27832195400*)[ 🏥 Safe Abortion Pills In Stanger...
Abortion Clinic In Stanger ](+27832195400*)[ 🏥 Safe Abortion Pills In Stanger...Abortion Clinic In Stanger ](+27832195400*)[ 🏥 Safe Abortion Pills In Stanger...
Abortion Clinic In Stanger ](+27832195400*)[ 🏥 Safe Abortion Pills In Stanger...
 
Team Transformation Tactics for Holistic Testing and Quality (NewCrafts Paris...
Team Transformation Tactics for Holistic Testing and Quality (NewCrafts Paris...Team Transformation Tactics for Holistic Testing and Quality (NewCrafts Paris...
Team Transformation Tactics for Holistic Testing and Quality (NewCrafts Paris...
 
UNI DI NAPOLI FEDERICO II - Il ruolo dei grafi nell'AI Conversazionale Ibrida
UNI DI NAPOLI FEDERICO II - Il ruolo dei grafi nell'AI Conversazionale IbridaUNI DI NAPOLI FEDERICO II - Il ruolo dei grafi nell'AI Conversazionale Ibrida
UNI DI NAPOLI FEDERICO II - Il ruolo dei grafi nell'AI Conversazionale Ibrida
 
GraphSummit Milan - Neo4j: The Art of the Possible with Graph
GraphSummit Milan - Neo4j: The Art of the Possible with GraphGraphSummit Milan - Neo4j: The Art of the Possible with Graph
GraphSummit Milan - Neo4j: The Art of the Possible with Graph
 
GraphSummit Milan - Visione e roadmap del prodotto Neo4j
GraphSummit Milan - Visione e roadmap del prodotto Neo4jGraphSummit Milan - Visione e roadmap del prodotto Neo4j
GraphSummit Milan - Visione e roadmap del prodotto Neo4j
 
CERVED e Neo4j su una nuvola, migrazione ed evoluzione di un grafo mission cr...
CERVED e Neo4j su una nuvola, migrazione ed evoluzione di un grafo mission cr...CERVED e Neo4j su una nuvola, migrazione ed evoluzione di un grafo mission cr...
CERVED e Neo4j su una nuvola, migrazione ed evoluzione di un grafo mission cr...
 
BusinessGPT - Security and Governance for Generative AI
BusinessGPT  - Security and Governance for Generative AIBusinessGPT  - Security and Governance for Generative AI
BusinessGPT - Security and Governance for Generative AI
 
Encryption Recap: A Refresher on Key Concepts
Encryption Recap: A Refresher on Key ConceptsEncryption Recap: A Refresher on Key Concepts
Encryption Recap: A Refresher on Key Concepts
 
Evolving Data Governance for the Real-time Streaming and AI Era
Evolving Data Governance for the Real-time Streaming and AI EraEvolving Data Governance for the Real-time Streaming and AI Era
Evolving Data Governance for the Real-time Streaming and AI Era
 
Abortion Pill Prices Germiston ](+27832195400*)[ 🏥 Women's Abortion Clinic in...
Abortion Pill Prices Germiston ](+27832195400*)[ 🏥 Women's Abortion Clinic in...Abortion Pill Prices Germiston ](+27832195400*)[ 🏥 Women's Abortion Clinic in...
Abortion Pill Prices Germiston ](+27832195400*)[ 🏥 Women's Abortion Clinic in...
 
Transformer Neural Network Use Cases with Links
Transformer Neural Network Use Cases with LinksTransformer Neural Network Use Cases with Links
Transformer Neural Network Use Cases with Links
 
Modern binary build systems - PyCon 2024
Modern binary build systems - PyCon 2024Modern binary build systems - PyCon 2024
Modern binary build systems - PyCon 2024
 
[GeeCON2024] How I learned to stop worrying and love the dark silicon apocalypse
[GeeCON2024] How I learned to stop worrying and love the dark silicon apocalypse[GeeCON2024] How I learned to stop worrying and love the dark silicon apocalypse
[GeeCON2024] How I learned to stop worrying and love the dark silicon apocalypse
 
OpenChain Webinar: AboutCode and Beyond - End-to-End SCA
OpenChain Webinar: AboutCode and Beyond - End-to-End SCAOpenChain Webinar: AboutCode and Beyond - End-to-End SCA
OpenChain Webinar: AboutCode and Beyond - End-to-End SCA
 
The mythical technical debt. (Brooke, please, forgive me)
The mythical technical debt. (Brooke, please, forgive me)The mythical technical debt. (Brooke, please, forgive me)
The mythical technical debt. (Brooke, please, forgive me)
 
[GRCPP] Introduction to concepts (C++20)
[GRCPP] Introduction to concepts (C++20)[GRCPP] Introduction to concepts (C++20)
[GRCPP] Introduction to concepts (C++20)
 
From Theory to Practice: Utilizing SpiraPlan's REST API
From Theory to Practice: Utilizing SpiraPlan's REST APIFrom Theory to Practice: Utilizing SpiraPlan's REST API
From Theory to Practice: Utilizing SpiraPlan's REST API
 
Workshop - Architecting Innovative Graph Applications- GraphSummit Milan
Workshop -  Architecting Innovative Graph Applications- GraphSummit MilanWorkshop -  Architecting Innovative Graph Applications- GraphSummit Milan
Workshop - Architecting Innovative Graph Applications- GraphSummit Milan
 

GC Tuning Confessions Of A Performance Engineer

  • 1. GC Tuning Confessions Of A Performance Engineer Monica Beckwith monica@codekaram.com @mon_beck www.linkedin.com/in/monicabeckwith Philly Emerging Tech Conference 2015 April 8th, 2015
  • 2. ©2015 CodeKaram About Me • JVM/GC Performance Engineer/Consultant • Worked at AMD, Sun, Oracle • Worked with HotSpot JVM • Worked with Parallel(Old) GC, G1 GC and CMS GC 2
  • 3. ©2015 CodeKaram About Today’s Talk • A little bit about Performance Engineering • Insight into Garbage Collectors • Introduction to a few main GC Algorithms in OpenJDK HotSpot (ParallelOld GC, CMS GC, and G1 GC) • Summary • GC Tunables 3
  • 4. ©2015 CodeKaram Performance Engineering • A performance engineer helps ensure that the system is designed + implemented to meet the performance requirements. • The performance requirements could include the service level agreements (SLAs) for throughput, latency and other response time related metrics - also known as non-functional requirements. • E.g. Response time (RT) metrics - Average (RT), max or worst-case RT, 99th percentile RT… • Let’s talk more about these RTs… 4
  • 5. ©2015 CodeKaram Performance Engineering - Response Time Metrics Average (ms) Minimum (ms) System1 307.741 7.622 System2 320.778 7.258 System3 321.483 6.432 System4 323.143 7.353 5
  • 6. ©2015 CodeKaram Performance Engineering - Response Time Metrics Average (ms) Number of GCs System1 307.741 37353 System2 320.778 34920 System3 321.483 36270 System4 323.143 40636 6
  • 7. ©2015 CodeKaram Performance Engineering - Response Time Metrics Average (ms) Maximum (ms) System1 307.741 3131.331 System2 320.778 2744.588 System3 321.483 1681.308 System4 323.143 20699.505 7
  • 8. ©2015 CodeKaram Performance Engineering - Response Time Metrics Average (ms) Maximum (ms) System1 307.741 3131.331 System2 320.778 2744.588 System3 321.483 1681.308 System4 323.143 20699.505 5 full GCs and 10 evacuation failures 8
  • 9. ©2015 CodeKaram Performance Engineering • Monitoring, analysis and tuning are a big part of performance engineering. • Monitoring utilization - CPU, IO, Memory bandwidth, Java heap, … • Analyzing utilization and time spent - GC logs, CPU, memory and application logs • Profiling - Application, System, Memory - Java Heap. • Java/JVM performance engineering includes the study, analysis and tuning of the Just-in-time (JIT) compiler, the Garbage Collector (GC) and many a times tuning related to the Java Development Kit (JDK). 9
  • 10. ©2015 CodeKaram Insight Into Garbage Collectors (GCs) • A GC is an automatic memory management unit. • An ideal GC is the one that requires minimum footprint (concurrent CPU or native memory), and provides maximum throughput while minimizing predictable latency. • Fun Fact - In reality you will have to tradeoff one (footprint or latency or throughput) in lieu of the others. A healthy performance engineering exercise can help you meet or exceed your goals. • Fun Fact - GC can NOT eliminate your memory leaks! • Fun Fact - GC (and heap dump) can provide an insight into your application. 10
  • 11. ©2015 CodeKaram GC Algorithms in OpenJDK HotSpot - The Tradeoff • Throughput and latency are the two main drivers towards refinement of GC algorithms. • Fun Fact - Most OpenJDK HotSpot users would like to increase their (Java) heap space but they fear full garbage collections. 11
  • 12. ©2015 CodeKaram GC Algorithms in OpenJDK HotSpot - Throughput Maximizer • Throughput has driven us to parallelization of GC worker threads: • Parallel Collection Threads • Parallel Concurrent Marking Threads • Throughput has driven us to generational GCs • Most objects die young. • Fast path allocation into “young” generation. • Age and then promote (fast path again) to “old” generation • Fun Fact: All GCs in OpenJDK HotSpot are generational. 12
  • 13. ©2015 CodeKaram GC Algorithms in OpenJDK HotSpot - Latency Sensitive • Latency has driven algorithms to no compaction or partial compaction • Time is of essence, no need to fully compact if free space is still available! • Latency has driven algorithms towards concurrency - i.e. running with the application threads. • Mostly concurrent mark and sweep (CMS) and concurrent marking in G1. • Fun Fact: All GCs in OpenJDK HotSpot fallback to a fully compacting stop-the-world garbage collection called the “full” GC. • Tuning can help avoid or postpone full GCs in many cases. 13
  • 14. ©2015 CodeKaram The Throughput Collector • ParallelOld is the throughput collector in OpenJDK HotSpot. • But, first, what is throughput? • Throughput is the percentage of time NOT spent in GC :) • The throughput goal for ParallelOld Collector is 99%. • That is, all the GC pauses that happen during the life of the application should account to 1% of the run time. • How does ParallelOld try to achieve its throughput goal? 14
  • 15. ©2015 CodeKaram The Throughput Collector - Java Heap Eden S0 S1 Old Generation Young Generation Allocations Survivors Tenured 15
  • 16. ©2015 CodeKaram • An allocation failure results in a stop-the-world young collection. • The young generation is collected in its entirety i.e. all objects (dead or alive) are emptied from the eden and S0 spaces. • After the young collection is complete, the surviving objects (objects that are live) are moved into S1. • Objects are aged in the survivor space until ready for promotion • When the age threshold is met, objects are promoted into the old generation. • Allocations and promotions are both fast tracked (lock-free) by using Thread/Promotion Local Allocation Buffers (TLAB/PLAB) The Throughput Collector - Young Collection 16
  • 17. ©2015 CodeKaram Old Generation Free Space Occupied Space The Throughput Collector - Contiguous Old Generation 17
  • 18. ©2015 CodeKaram Old Generation To-be Promoted Object 1 The Throughput Collector - Contiguous Old Generation 18
  • 19. ©2015 CodeKaram Old Generation Free Space Occupied Space The Throughput Collector - Contiguous Old Generation 19
  • 20. ©2015 CodeKaram Old Generation To-be Promoted Object 2 The Throughput Collector - Contiguous Old Generation 20
  • 21. ©2015 CodeKaram Old Generation Free Space Occupied Space The Throughput Collector - Contiguous Old Generation 21
  • 22. ©2015 CodeKaram Old Generation To-be Promoted Object 3 The Throughput Collector - Contiguous Old Generation 22
  • 23. ©2015 CodeKaram • When the old generation is full, i.e. when the old generation can’t accept any promotions, it is time to start a full compaction collection. • The ParallelOld collector utilized parallel stop-the-world GC threads to help compact the entire heap. • The ParallelOld collector achieves compaction via copying and moving live data. • After the end of the full collection, only the compacted live data set of the java application occupies the old generation. The rest of the space in the old generation is free for future promotions. The Throughput Collector - Contiguous Old Generation 23
  • 25. ©2015 CodeKaram The CMS Collector • Mostly Concurrent Mark & Sweep collector is geared towards latency sensitive applications. • The young collections are pretty similar to what you would observe with ParallelOld GC’s young collection • The main difference is in the old generation collection. • An occupancy threshold determines when the mostly concurrent mark and sweep cycle can start. • The sweep cycle just reclaims the dead objects and updates a list of free spaces. Thus, the CMS collector is not a compacting collector. • This can lead to fragmentation which can lead to promotion failures which eventually lead to a fallback single-threaded fully compacting collection. 25
  • 26. ©2015 CodeKaram The CMS Collector • The CMS collector has multiple stop-the-world and concurrent phases - • After the old generation occupied space reaches or crosses the occupancy threshold, a CMS cycle is initiated. • Initially, parallel stop-the-world CMS threads help find the GC roots to start a live object graph. • Concurrent CMS threads help in marking further live objects (objects that are reachable by the roots). • Parallel stop-the-world CMS threads help in making sure that the final changes to the graph are duly noted. • Concurrent sweep phase helps in collecting all dead objects and updating the free list to track the reclaimed spaces. 26
  • 27. ©2015 CodeKaram The CMS Collector Young GC Threads Java Application Threads CMS Initial Mark Threads Java Application Threads Java Application Threads Young GC Threads CMS Remark Threads Java Application Threads Java Application Threads Concurrent CMS Threads Concurrent CMS Threads Concurrent CMS Threads 27
  • 28. ©2015 CodeKaram The CMS Collector - Contiguous Old Generation 28 Old Generation Free List Free Space Occupied Space
  • 29. ©2015 CodeKaram Old Generation To-be Promoted Object 1 The CMS Collector - Contiguous Old Generation 29
  • 30. ©2015 CodeKaram Old Generation Free List Free Space Occupied Space The CMS Collector - Contiguous Old Generation 30
  • 31. ©2015 CodeKaram Old Generation To-be Promoted Object 2 The CMS Collector - Contiguous Old Generation 31
  • 32. ©2015 CodeKaram Old Generation Free List Free Space Occupied Space The CMS Collector - Contiguous Old Generation 32
  • 33. ©2015 CodeKaram X Old Generation To-be Promoted Object 3 The CMS Collector - Contiguous Old Generation 33
  • 34. ©2015 CodeKaram X Old Generation To-be Promoted Object 3 The CMS Collector - Contiguous Old Generation 34
  • 35. ©2015 CodeKaram X Old Generation To-be Promoted Object 3 The CMS Collector - Contiguous Old Generation 35
  • 36. ©2015 CodeKaram X Old Generation To-be Promoted Object 3 The CMS Collector - Contiguous Old Generation 36
  • 37. ©2015 CodeKaram Old Generation To-be Promoted Object 3 ?? The CMS Collector - Contiguous Old Generation 37
  • 38. ©2015 CodeKaram Old Generation To-be Promoted Object 3 Promotion Failure!! The CMS Collector - Contiguous Old Generation 38
  • 39. ©2015 CodeKaram • When CMS just can’t keep up with the promotion rate • Your old generation is getting filled before a concurrent cycle can free up space and complete. • Causes - marking threshold is too high, heap too small, or high application mutation rate 39 The CMS Collector - Concurrent Mode Failures
  • 40. ©2015 CodeKaram The Garbage First Collector • Garbage First (G1) is the newest collector in OpenJDK HotSpot. • G1 GC is supposed to be a long term replacement of CMS GC. • G1 GC introduces the concept of regionalized heap. • The idea is to set a pause time goal which will be used as a hint by the ergonomics and prediction logic and G1 GC will try to adjust its generations and number of regions per collections so as to best meet its pause time goal. • G1 has multi-staged concurrent marking phase as well as stop the world collections for young and old generations 40
  • 41. ©2015 CodeKaram The Garbage First Collector • Throughput is a secondary consideration for G1. Hence the throughput goal is to have about 10% of the total time be spent in GC activities. • G1 GC aims to provide more predictable pause times. • The G1 GC regionalized heap ensures that the generations don’t have to be contiguous (as they were in ParallelOld and CMS GCs). • With regions, G1 just needs to know the limits for each generation and the pause time goal. • G1 will add regions as needed from the list of free regions. • Occupied regions can be eden, survivor, old and humongous (more on this later). 41
  • 42. ©2015 CodeKaram The Garbage First Collector - Regionalized Heap Eden Old Old Eden Old Survivor Humongous 42
  • 43. ©2015 CodeKaram • For G1 GC, the young generation consists of eden regions and survivor regions. • A region is a unit of collection • The region size is determined at JVM startup (and can be changed if needed) • Most allocations are fast path allocations into the eden regions. • The survivor regions help in aging the objects which are eventually promoted into the old generation after the age threshold is crossed • The young generation is resized after every collection based on the time it took the current collection, the pause time goal and other factors considered by the prediction logic. The Garbage First Collector - The Young Generation 43
  • 44. ©2015 CodeKaram The Garbage First Collector Eden Old Old Eden Old Surv ivor E.g.: Current heap configuration - 44
  • 45. ©2015 CodeKaram The Garbage First Collector Eden Old Old Eden Old Surv ivor E.g.: During a young collection - 45
  • 46. ©2015 CodeKaram The Garbage First Collector Old Old Old E.g.: After a young collection - Sur vivor Old 46
  • 47. ©2015 CodeKaram • For G1 GC, the old generation collection consists of all of the young regions and a few candidate old regions. Such a collection is called a mixed collection. • The GC ergonomics selects the candidate old regions based on certain thresholds and calculations that help determine the regions with the most reclaimable space and at the same time giving consideration to the pause time goal. • Based on the total number of candidate old regions, the pause time goal and other collection related thresholds, you could see more that one mixed collection pause. Thus the old generation is collected incrementally. The Garbage First Collector - The Old Generation 47
  • 48. ©2015 CodeKaram • In-order to start a mixed collection, the heap occupancy threshold (also known as the marking threshold) must be crossed. • When the marking threshold is crossed, G1 GC initiates a concurrent marking cycle. The concurrent cycle is mostly concurrent, except for when marking the roots and when remarking to make sure all the mutations are captured appropriately in the object graph. • During the concurrent marking phase, any garbage-filled regions are reclaimed as a part of the cleanup phase. The Garbage First Collector - The Marking Threshold 48
  • 49. ©2015 CodeKaram The Garbage First Collector Old Old Old E.g.: Current heap configuration - Sur vivor Old Eden Eden Old 49
  • 50. ©2015 CodeKaram Old Old Old E.g.: Reclamation of a garbage-filled region during a concurrent cleanup phase - Sur vivor Old Eden Eden Old The Garbage First Collector 50
  • 51. ©2015 CodeKaram Old Old Old E.g.: Current heap configuration - Sur vivor Old Eden Eden The Garbage First Collector 51
  • 52. ©2015 CodeKaram Old Old Old E.g.: During a mixed collection - Sur vivor Old Eden Eden The Garbage First Collector 52
  • 53. ©2015 CodeKaram Old E.g.: After a mixed collection - O ld Surv ivor Old The Garbage First Collector 53
  • 54. ©2015 CodeKaram • Objects >= 50% of G1 region size == Humongous Objects • These objects are allocated directly into the old generation into Humongous Regions • If a humongous object is bigger than a G1 region, then the humongous regions that contain it have to be contiguous. • Ideally, humongous objects are few in number and are short lived. • Can cause evacuation failures if application allocates a lot of long-lived humongous objects, since humongous regions add to the old generation occupancy. The Garbage First Collector - Humongous Objects 54
  • 55. ©2015 CodeKaram • Evacuation failures or promotion failures or to- space overflow or exhausted all refer to the same notion. • When there are no more regions available for survivors or tenured objects, G1 GC encounters an evacuation failure. • An evacuation failure is expensive and the usual pattern is that if you see a couple of evacuation failures; full GC will soon follow. The Garbage First Collector - Evacuation Failures 55
  • 56. ©2015 CodeKaram • Make sure your command line is not overloaded - Avoid over- tuning! • Try increasing your heap size. • Check if humongous allocations are the cause of your problem. • Adjust the marking threshold • Try increasing your concurrent threads to help reduce the time for concurrent marking phase. • If survivor objects are the issue, try increase the G1ReservePercent The Garbage First Collector - Avoiding Evacuation Failures 56
  • 57. ©2015 CodeKaram What have we learned so far? - Young Generation & Collections • Young generation is always collected in its entirety. • All 3 GCs discussed earlier follow similar mechanism for young collection. • The young collections achieve reclamation via compaction and copying of live objects. • There are a lot of options for sizing the Eden and Survivor space optimally and many GCs also have adaptive sizing and ergonomics for young generation collections. 57
  • 58. ©2015 CodeKaram Most Allocations Eden Space Eden Full? Start Young Collection: Keep Allocating :) Objects Aged in Survivor Space? Promote: Keep Aging :) Fast Path Promotions Fast Path Old Generation CMS promotes to fitting free space out of a free list. What have we learned so far? - Young Generation & Collections 58
  • 59. ©2015 CodeKaram All 3 GCs vary in the way they collect the old generation: • For ParallelOld GC, the old generation is reclaimed and compacted in its entirety • Luckily, the compaction cost is distributed amongst parallel garbage collector worker threads. • Unluckily, the compaction cost depends a lot on the size of the live data set since at every compaction, the GC is moving live data around. • No tuning options other than the generation size adjustment and age threshold for promotion. 59 What have we learned so far? - Old Generation & Collections
  • 60. ©2015 CodeKaram • For CMS GC, the old generation is (mostly) concurrently marked and swept. Thus the reclamation of dead objects happen in place and the space is added to a free list of spaces. • The marking threshold can be tuned adaptively and manually as well. • Luckily, CMS GC doesn’t do compaction, hence reclamation is fast. • Unluckily, a long running Java application with CMS GC is prone to fragmentation which will eventually result in promotion failures which can eventually lead to full compacting garbage collection and sometimes even concurrent mode failures. • Full compacting GCs are singled threaded in CMS GC. What have we learned so far? - Old Generation & Collections 60
  • 61. ©2015 CodeKaram • For G1 GC, the old generation regions are (mostly) concurrently marked and an incremental compacting collection helps with optimizing the old generation collection. • Luckily, fragmentation is not “untunable” in G1 GC as it is in CMS GC. • Unluckily, sometimes, you may still encounter promotion/evacuation failures when G1 GC runs out of regions to copy live objects. Such an evacuation failure is expensive and can eventually lead to a full compacting GC. • Full compacting GCs are singled threaded in G1 GC. • Appropriate tuning of the old generation space and collection can help avoid evacuation failures and hence keep full GCs at bay. • G1 GC has multiple tuning options so that the GC can be adapted to your application needs. 61 What have we learned so far? - Old Generation & Collections
  • 62. ©2015 CodeKaram GC Tunables - The Throughput Collector Goal: Only promote objects after you have hazed them appropriately aged Tunables: Everything related to aging objects and generation sizing - NewRatio, (Max)NewSize, SurvivorRatio, (Max)TenuringThreshold 62
  • 63. ©2015 CodeKaram GC Tunables - The Throughput Collector Things to remember - • Applications with steady behavior rarely need AdaptiveSizePolicy to be enabled. • Overflow gets promoted into the old generation • Provide larger survivor spaces for long-lived transient data. • In most cases, young generation sizing has the most effect on throughput • Size the young generation to maintain the GC overhead to less than 5%. 63
  • 64. ©2015 CodeKaram GC Tunables - The CMS Collector Goal: Only promote objects after you have hazed them appropriately aged Tunables: Everything related to aging objects and young generation sizing still applies here. The concurrent thread counts and marking threshold are addition tunables for CMS 64
  • 65. ©2015 CodeKaram GC Tunables - The CMS Collector Things to remember - • Premature promotions are very expensive in CMS and could lead to fragmentation • You can reduce the CMS cycle duration by adding more concurrent threads: ConcGCThreads. • Remember that this will increase the concurrent overhead. • You can manually tune the marking threshold (adaptive by default) • CMSInitiatingOccupancyFraction & UseCMSInitiatingOccupancyOnly will help fix the marking threshold. • Note: The threshold is expressed as a percentage of the old generation occupancy 65
  • 66. ©2015 CodeKaram GC Tunables - The G1 Collector Goal: Get the ergonomics to work for you and know the defaults Tunables: • Pause time goal, heap size, max and min nursery, concurrent and parallel threads • The marking threshold, number of mixed GCs after marking, liveness threshold for the old regions, garbage toleration threshold, max old regions to be collected per mixed collection 66
  • 67. ©2015 CodeKaram GC Tunables - The G1 Collector Things to remember - • Know your defaults! • Understand your G1HeapRegionSize - It could be any factor of two from 1MB to 32MB. G1 strives for 2048 regions. • Fixing the nursery size (using Xmn) will meddle with the GC ergonomics. • Don’t set really aggressive pause time goals - this will increase the GC overhead. • Spend time taming your mixed GCs - mixed GCs are incremental old generation collections 67
  • 68. ©2015 CodeKaram GC Tunables - The G1 Collector Things to remember - • Taming mixed GCs: • Adjust the marking cycle according to you live data set. • Adjust you liveness threshold - this is the live occupancy threshold per region. Any region with liveness beyond this threshold will not be included in a mixed collection. • Adjust your garbage toleration threshold - helps G1 not get too aggressive with mixed collections • Distribute mixed GC pauses over a number of mixed collections - adjust your mixed GC count target and change your max old region threshold percent so that you can limit the old regions per collection 68
  • 71. ©2015 CodeKaram Further Reading • Jon Masa’s blog: https://blogs.oracle.com/ jonthecollector/entry/our_collectors • A few of my articles on InfoQ: http:// www.infoq.com/author/Monica-Beckwith • Presentations: http://www.slideshare.net/ MonicaBeckwith • Mail archives on hotspot-gc-use@openjdk.java.net & hotspot-gc-dev@openjdk.java.net 71