Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

JVM and Garbage Collection Tuning


Published on

Published in: Technology
  • If you're interested in realtime garbage collection monitoring you can also take a look at this free VisualVM plugin:
    Are you sure you want to  Yes  No
    Your message goes here

JVM and Garbage Collection Tuning

  1. 1. JVM & GC Tuning Kai Koenig,Ventego Creative Ltd
  2. 2. Why?Reasons for tuning your JVM:. Growth vs. Resources. Performance issues. Error messages. Hardware scalability
  3. 3. Why?Typical issues:. Memory Leaks. Out-of-memory issues. Looooooooong Garbage Collection Pauses
  4. 4. JVM MemoryWe’re looking at the JVM heap memory fromnow on!. This is where your objects and classes arebeing held while the JVM is running. Basic assumption: lots of short-lived objects,few long-lived objects. Note: even local objects within a methodend up on the heap
  5. 5.
  6. 6. Heap managementFor the JVM it’s impossible to know inadvance how your a certain object will live.. Solution is a generational management..Young Generation (Eden, Survivor Spaces).. Tenured/Old Generation.. Permanent Generation
  7. 7. Young GenerationEvery single newly created object is createdhere.. In general: GC in the YG should happenoften and shouldn’t take long. If an object survives a certain number of GCin the YG the JVM assumes that the object islong-lived -> moved into Old Generation
  8. 8. Old GenerationThe Old Generation fills up more and moreand at some stage there will be a GChappening in there. Often the OldGen is much larger than theYG -> GC might take long(er). GC stop the JVM - big problem if yourOldGen GC takes multiple seconds
  9. 9. Further issuesIf one is short on operating system memoryand (parts of) the JVM is in Swap Space, a GCin the OldGen can take minutes.. Always make sure that the JVM fits into themain memory of the server. Rule of thumb: Avoid OldGen GCswhenever you can!
  10. 10. Typical examplesshort-lived:. Local variables/objects, iterators in a loopetcmedium-lived:. Session-based informationlong-lived:. Thread pools, singletons, frameworks
  11. 11.
  12. 12. Why is that good?Where there is lots of garbage, cleaning upthe garbage fast is really worthwhile. Cleaning up the YG often means we havespace for new, fresh objects. The GC doesn’t have to search the wholeheap for unused objects but just a certaingeneration at a time. Objects die appropriately
  13. 13. TerminologyYG Collections: Minor CollectionsMajor/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]
  14. 14. Permanent GenerationPermGen. Class objects, internal JVM objects, JITinformation. Urban myth: It’s not part of the “real” heap -so you don’t have to worry.
  15. 15.
  16. 16. YG internalsThe YG consists of Eden and two Survivorspaces. new/newInstance() create objects in Eden (ifan object is larger than Eden it will becreated in the OldGen). One Survivor space is always empty, duringYG GC the JVM will copy survivors in Edenand S1 to S2 and vice versa
  17. 17. OldGen internalsThe amount of survived GCs is calledTenuring Threshold -> “Promotion”. Note: Sometimes objects get promoted toOldGen because Survivor spaces are toosmallAlternatives: Have one GC for the wholeheap. Efficiency?
  18. 18. Selecting a GCWith YG and OldGen being dealt withseparately we can now further selectdifferent GC algorithms. Factors:. Efficiency/Throughput. Pauses and Concurrency. Overhead
  19. 19. How to choose?Depends on the JVM.... Sun’s Java 5/6 JVM comes pre-setup withcertain criteria for selecting GC strategiesand settings (“Ergonomics”) - most can bechanged. JRockit / Apple JVMs similar
  20. 20. YG Collectors. Mark-and-Sweep: Marking phase to get all“reachable” objects, sweeping phase cleansheap.. Problem: fragmentation and issues whenallocating new memory. Note: I have seen cases wherefragmentation led to out-of-memory issues
  21. 21. YG Collectors. Mark-and-Copy: Marking phase to get all“reachable” objects, copy those into a newarea. No fragmentation, but extra scavengingphase, JVM holds slightly more memory thanneeded. Lends itself to the E+S1+S2 concept
  22. 22. InterGen ReferenceThere is extra effort involved to keep trackof references from OldGen to YG.. Card Tables, Dirty Markers etc
  23. 23. Parallel GC in the YGMark-and-Copy is “Stop-The-World”-GC. Single Reaper-Thread. Since Java 1.4.2 we have a Parallel GC in theYG, there is still a “Stop-The-World” pause,but it’s much shorter!. Default YG GC since Java 5 if machine hasmultiple cores or CPUs
  24. 24. Parallel GC in the YGSome JVM args-XX:+UseParallelGC-XX:ParallelGCThreads=<n>
  25. 25. OldGen CollectorsLots of objects, low mortality - Mark-and-Copy would be inefficient: Mark-and-Compact.Variation of Mark-and-Sweep (reducedfragmentation). Quite involved: Marking, Calculation of newlocations, Reference Adjustments, Moving
  26. 26. OldGen CollectorsMark-and-Compact is expensive if we havelots of surviving objects and if we have alarge heap. Big downside: serial collector - stops allthreads
  27. 27. OldGen CollectorsParallel Mark-and-Compact:-XX:+UseParallelOldGC (since Java 5 upd 6)Concurrent-Mark-and-Sweep (CMS):-XX:+UseConcMarkSweepGC (since Java1.4.1) - keep the issue of fragmentation inmind
  28. 28. Default selections. OldGen: Since Java 6 parallel Mark-and-Compact is default on server profiles (useJVM args in Java 5 and client profiles).YG: Since Java 5 parallel Mark-and-Copy isdefault on server profiles (use JVM args inJava 1.4.x and client profiles)
  29. 29. Some thoughts. Concurrent Mark-and-Sweep is thepreferred OldGen collector if you want toavoid “Stop-The-World” collections by allmeans.. Overall throughput slightly less than theparallel Mark-and-Compact collector, butmuch better suited for web apps. Well suited for large heaps (actually youneed large heaps for CMS)
  30. 30. Memory sizingInitial and maximum heap size:-Xms6144m, -Xmx6144mPermGen size:-XX:MaxPermSize=256mYG size:-XX:NewSize=2500m, -XX:MaxNewSize=2500m
  31. 31. ExampleExtremely 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
  32. 32. GC Tuning. Make assumptions for load, memory sizingand GC settings. Run load tests, Monitor, Measure. Use tools: Fusion Reactor, GCViewer,VisualGC etc.. Learn, change one setting and repeat cycle
  33. 33. GC Tuning. GC Throughput: 95%+ are seen as good. In aweb app environment I don’t like anythingbelow 97%. Go for pause tuning if GC pauses are anissue. Memory is usually not an issue anymore intoday’s 64-bit world, be aware of 64-bitoverhead though
  34. 34. Overview Max throughput Min pause time 2+ cores 1/2 cores 2+ cores 1/2 cores YG par YG ser YG par YG ser YGOldGen par OG ser OG CMS -XX: -XX:JVM Flag +UseParallelGC +UseSerialGC -XX:+UseConcMarkSweepGC
  35. 35. Tools
  36. 36. Get in touchKai Koenig. Email: Work: Blog: Twitter: @AgentK