First steps in GC tuning

Transcript

1. First steps in GC tuning
2. Who am I • Nikita Salnikov-Tarnovski • Founder and Master Developer from • @iNikem / @JavaPlumbr
3. What this talk is about • 80% of GC problems are easy to fix • Here are low hanging fruits
4. What this talk is NOT about • Silver bullet that makes your application fast • Obscure options to squeeze last 10%
5. Where it begins • Sometimes your application stalls • Application is slow • SLA is broken
6. What we do? • PROFILE! • Wrong • GC? • May be
7. How GC can be a problem
8. Collect evidence • Collect GC logs from production • -XX:+PrintGCDetails • -XX:+PrintGCTimeStamps • -Xloggc:file.log
9. GC overhead • Share of CPU consumed by GC • Affects your application’s throughput • Rule of thumb: <5-10%
10. GC latency • Duration of individual GC pause • Directly affects end-user perception • Often more important • But more difficult
11. The basis of GC
12. Heap size • GC duration does NOT depend on heap size • And does NOT depend on total objects • BUT on the live objects
13. Change the application • The only option with 100% success • Put your application on memory diet • Not always worth it
14. Goals of GC tuning Latency Heap size Overhead
15. Let me tune! • java -XX:+PrintFlagsFinal • More than 700 JVM flags • More than 200 of them are GC related
16. Before you start • Ensure that you have no memory leaks • If you have, GC tuning is useless
17. 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
18. This is bad way to start
19. Good way to start • State your performance goals • Remove all GC related params from your JVM • Run load tests • Measure • Compare to goals
20. Two ways • Understand intimate details of GC • Collect exact metrics • Calculate exact values • Get the best possible result • Understand that options field is finite • Try most probable • Pick the best • Be pleased and go home Theoretical Practical
21. 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
22. Object lifecycle
23. Serial
24. Serial • -XX:+UserSerialGC • Was meant for singe core machines • And heaps of some 100s MBs • But the smallest overhead during run
25. Parallel
26. Parallel • -XX:+UseParallelGC • a.k.a “Throughput” • Usually, but not always, N times faster than Serial • Occasionally long pauses can occur
27. ConcurrentMarkSweep Young Old
28. 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
29. 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.
30. G1 • -XX:+UseG1GC • Slowly becoming more popular • Use in jdk8 only, the newer the better • There are plans to make it default in jdk9
31. Case1 Summary Throughout Largest Pause Parallel+3G 85,7% 0,4 Parallel+4G 98% 0,39 Parallel+6G 98% 0,38 CMS+4G 95,8% 0,06
32. Case2 Summary Throughout Largest Pause Parallel+8G OOM OOM CMS+8G 62% 1,64 CMS+12G 89% 0,19 Parallel+12G 82,3% 1,14 Parallel+12G* 90,5% 1,24 G1+12G+jdk7 92,35 1,56 G1+12G+jdk8 93% 1,36
33. 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
34. External factors • Other applications and OS • Can be a source of mysterious long pauses • Look for high system time in GC logs
35. Solving performance problems is hard. We don’t think it needs to be.