JVM and Garbage Collection Tuning
9 likes3,170 views
The document discusses tuning the Java Virtual Machine (JVM) and garbage collection (GC) to improve performance and prevent issues like memory leaks and out-of-memory errors. It explains how the JVM manages memory using different generations like the young and old generations and different GC algorithms for each. It also provides recommendations on how to select GC settings and monitor performance based on factors like throughput, pause times, and hardware.
![Terminology
YG Collections: Minor Collections
Major/Full Garbage Collections clean up both
[GC 64781K->22983K(71360K), 0.0242084 secs]
YG and OldGen [GC 68487K->25003K(77888K), 0.0194041 secs]
[Full GC 25003K->20302K(89600K), 0.1713420 secs]
[GC 70670K->21755K(90048K), 0.0054093 secs]
[GC 71913K->46558K(94912K), 0.0295257 secs]
[Full GC 46558K->45267K(118336K), 0.2144038 secs]
How to find out?
[GC 88214K->84651K(133056K), 0.0674443 secs]
[Full GC 84651K->84633K(171648K), 0.1739369 secs]
[GC 117977K->115114K(180736K), 0.0623399 secs]
[GC 158613K->157136K(201152K), 0.0591171 secs]
[Full GC 157136K->157098K(254784K), 0.1868453 secs]
[GC 160678K->160455K(261184K), 0.0536678 secs]
. use -verbose:GC in your 01/24 19:36:22 Debug [scheduler-1] - Next mail spool run in 15 seconds.
[GC 202912K->200819K(268288K), 0.0625820 secs]
[Full GC 200819K->200776K(332224K), 0.2121724 secs]
[GC 213293K->212423K(339520K), 0.0426462 secs]
JVM args [GC 259465K->256115K(340288K), 0.0645039 secs]
[Full GC 256115K->255462K(418432K), 0.3226731 secs]
[GC 281947K->279651K(421760K), 0.0530268 secs]
[GC 331073K->323785K(422720K), 0.0695117 secs]
[Full GC 323785K->323697K(459264K), 0.2139458 secs]
[Full GC 364365K->361525K(459264K), 0.2180439 secs]
[Full GC 400859K->400859K(459264K), 0.1702890 secs]
[Full GC 400859K->43989K(274112K), 0.2642407 secs]
[GC 95197K->93707K(273216K), 0.0338568 secs]
[GC 146978K->140363K(276032K), 0.0664380 secs]
[GC 193696K->189635K(277952K), 0.0630006 secs]
[Full GC 189635K->189604K(425920K), 0.1913979 secs]
[GC 219773K->205157K(426048K), 0.0442126 secs]](https://image.slidesharecdn.com/memoryjvm-111117192058-phpapp02/85/JVM-and-Garbage-Collection-Tuning-16-320.jpg)
JVM and Garbage Collection Tuning
- 1. JVM & GC Tuning Kai Koenig,Ventego Creative Ltd
- 2. Why? Reasons for tuning your JVM: . Growth vs. Resources . Performance issues . Error messages . Hardware scalability
- 3. Why? Typical issues: . Memory Leaks . Out-of-memory issues . Looooooooong Garbage Collection Pauses
- 4. JVM Memory We’re looking at the JVM heap memory from now on! . This is where your objects and classes are being held while the JVM is running . Basic assumption: lots of short-lived objects, few long-lived objects . Note: even local objects within a method end up on the heap
- 6. Heap management For the JVM it’s impossible to know in advance how your a certain object will live. . Solution is a generational management ..Young Generation (Eden, Survivor Spaces) .. Tenured/Old Generation .. Permanent Generation
- 8. Young Generation Every single newly created object is created here. . In general: GC in the YG should happen often and shouldn’t take long . If an object survives a certain number of GC in the YG the JVM assumes that the object is long-lived -> moved into Old Generation
- 10. Old Generation The Old Generation fills up more and more and at some stage there will be a GC happening in there . Often the OldGen is much larger than the YG -> GC might take long(er) . GC stop the JVM - big problem if your OldGen GC takes multiple seconds
- 12. Further issues If one is short on operating system memory and (parts of) the JVM is in Swap Space, a GC in the OldGen can take minutes. . Always make sure that the JVM fits into the main memory of the server . Rule of thumb: Avoid OldGen GCs whenever you can!
- 13. Typical examples short-lived: . Local variables/objects, iterators in a loop etc medium-lived: . Session-based information long-lived: . Thread pools, singletons, frameworks
- 14. http://www.flickr.com/photos/thomashawk/3958193579/
- 15. Why is that good? Where there is lots of garbage, cleaning up the garbage fast is really worthwhile . Cleaning up the YG often means we have space for new, fresh objects . The GC doesn’t have to search the whole heap for unused objects but just a certain generation at a time . Objects die appropriately
- 16. Terminology YG Collections: Minor Collections Major/Full Garbage Collections clean up both [GC 64781K->22983K(71360K), 0.0242084 secs] YG and OldGen [GC 68487K->25003K(77888K), 0.0194041 secs] [Full GC 25003K->20302K(89600K), 0.1713420 secs] [GC 70670K->21755K(90048K), 0.0054093 secs] [GC 71913K->46558K(94912K), 0.0295257 secs] [Full GC 46558K->45267K(118336K), 0.2144038 secs] How to find out? [GC 88214K->84651K(133056K), 0.0674443 secs] [Full GC 84651K->84633K(171648K), 0.1739369 secs] [GC 117977K->115114K(180736K), 0.0623399 secs] [GC 158613K->157136K(201152K), 0.0591171 secs] [Full GC 157136K->157098K(254784K), 0.1868453 secs] [GC 160678K->160455K(261184K), 0.0536678 secs] . use -verbose:GC in your 01/24 19:36:22 Debug [scheduler-1] - Next mail spool run in 15 seconds. [GC 202912K->200819K(268288K), 0.0625820 secs] [Full GC 200819K->200776K(332224K), 0.2121724 secs] [GC 213293K->212423K(339520K), 0.0426462 secs] JVM args [GC 259465K->256115K(340288K), 0.0645039 secs] [Full GC 256115K->255462K(418432K), 0.3226731 secs] [GC 281947K->279651K(421760K), 0.0530268 secs] [GC 331073K->323785K(422720K), 0.0695117 secs] [Full GC 323785K->323697K(459264K), 0.2139458 secs] [Full GC 364365K->361525K(459264K), 0.2180439 secs] [Full GC 400859K->400859K(459264K), 0.1702890 secs] [Full GC 400859K->43989K(274112K), 0.2642407 secs] [GC 95197K->93707K(273216K), 0.0338568 secs] [GC 146978K->140363K(276032K), 0.0664380 secs] [GC 193696K->189635K(277952K), 0.0630006 secs] [Full GC 189635K->189604K(425920K), 0.1913979 secs] [GC 219773K->205157K(426048K), 0.0442126 secs]
- 17. Permanent Generation PermGen . Class objects, internal JVM objects, JIT information . Urban myth: It’s not part of the “real” heap - so you don’t have to worry.
- 19. YG internals The YG consists of Eden and two Survivor spaces . new/newInstance() create objects in Eden (if an object is larger than Eden it will be created in the OldGen) . One Survivor space is always empty, during YG GC the JVM will copy survivors in Eden and S1 to S2 and vice versa
- 21. OldGen internals The amount of survived GCs is called Tenuring Threshold -> “Promotion” . Note: Sometimes objects get promoted to OldGen because Survivor spaces are too small Alternatives: Have one GC for the whole heap. Efficiency?
- 22. Selecting a GC With YG and OldGen being dealt with separately we can now further select different GC algorithms. Factors: . Efficiency/Throughput . Pauses and Concurrency . Overhead
- 23. How to choose? Depends on the JVM... . Sun’s Java 5/6 JVM comes pre-setup with certain criteria for selecting GC strategies and settings (“Ergonomics”) - most can be changed . JRockit / Apple JVMs similar
- 24. YG Collectors . Mark-and-Sweep: Marking phase to get all “reachable” objects, sweeping phase cleans heap. . Problem: fragmentation and issues when allocating new memory . Note: I have seen cases where fragmentation led to out-of-memory issues
- 25. YG Collectors . Mark-and-Copy: Marking phase to get all “reachable” objects, copy those into a new area . No fragmentation, but extra scavenging phase, JVM holds slightly more memory than needed . Lends itself to the E+S1+S2 concept
- 26. InterGen Reference There is extra effort involved to keep track of references from OldGen to YG. . Card Tables, Dirty Markers etc
- 27. Parallel GC in the YG Mark-and-Copy is “Stop-The-World”-GC . Single Reaper-Thread . Since Java 1.4.2 we have a Parallel GC in the YG, there is still a “Stop-The-World” pause, but it’s much shorter! . Default YG GC since Java 5 if machine has multiple cores or CPUs
- 28. Parallel GC in the YG Some JVM args -XX:+UseParallelGC -XX:ParallelGCThreads=<n>
- 29. OldGen Collectors Lots of objects, low mortality - Mark-and- Copy would be inefficient: Mark-and- Compact .Variation of Mark-and-Sweep (reduced fragmentation) . Quite involved: Marking, Calculation of new locations, Reference Adjustments, Moving
- 30. OldGen Collectors Mark-and-Compact is expensive if we have lots of surviving objects and if we have a large heap . Big downside: serial collector - stops all threads
- 31. OldGen Collectors Parallel Mark-and-Compact: -XX:+UseParallelOldGC (since Java 5 upd 6) Concurrent-Mark-and-Sweep (CMS): -XX:+UseConcMarkSweepGC (since Java 1.4.1) - keep the issue of fragmentation in mind
- 32. Default selections . OldGen: Since Java 6 parallel Mark-and- Compact is default on server profiles (use JVM args in Java 5 and client profiles) .YG: Since Java 5 parallel Mark-and-Copy is default on server profiles (use JVM args in Java 1.4.x and client profiles)
- 33. Some thoughts . Concurrent Mark-and-Sweep is the preferred OldGen collector if you want to avoid “Stop-The-World” collections by all means. . Overall throughput slightly less than the parallel Mark-and-Compact collector, but much better suited for web apps . Well suited for large heaps (actually you need large heaps for CMS)
- 35. Memory sizing Initial and maximum heap size: -Xms6144m, -Xmx6144m PermGen size: -XX:MaxPermSize=256m YG size: -XX:NewSize=2500m, -XX:MaxNewSize=2500m
- 36. Example Extremely high-volume/traffic sites - optimization goal: pause times -Xms6144m -Xmx6144m -XX:NewSize=2500m -XX:MaxNewSize=2500m -XX:+CMSIncrementalMode -XX:+ExplicitGCInvokesConcurrent -XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=384m -XX:PermSize=384m -XX:+UseConcMarkSweepGC
- 37. GC Tuning . Make assumptions for load, memory sizing and GC settings . Run load tests, Monitor, Measure . Use tools: Fusion Reactor, GCViewer, VisualGC etc. . Learn, change one setting and repeat cycle
- 38. GC Tuning . GC Throughput: 95%+ are seen as good. In a web app environment I don’t like anything below 97% . Go for pause tuning if GC pauses are an issue . Memory is usually not an issue anymore in today’s 64-bit world, be aware of 64-bit overhead though
- 39. Overview Max throughput Min pause time 2+ cores 1/2 cores 2+ cores 1/2 cores YG par YG ser YG par YG ser YG OldGen par OG ser OG CMS -XX: -XX: JVM Flag +UseParallelGC +UseSerialGC -XX:+UseConcMarkSweepGC
- 40. Tools
- 41. Get in touch Kai Koenig . Email: [email protected] . Work: www.ventego-creative.co.nz . Blog: www.bloginblack.de . Twitter: @AgentK