JVM and Garbage Collection Tuning

  • 2,931 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
  • If you're interested in realtime garbage collection monitoring you can also take a look at this free VisualVM plugin: http://www.spyglasstools.com/documentation/spyglass-garbage-collector-analyzer/
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
2,931
On Slideshare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
1
Likes
8

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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 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. http://www.flickr.com/photos/museemccordmuseum/3294656277/
  • 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. 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. 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. 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. Typical examplesshort-lived:. Local variables/objects, iterators in a loopetcmedium-lived:. Session-based informationlong-lived:. Thread pools, singletons, frameworks
  • 11. http://www.flickr.com/photos/thomashawk/3958193579/
  • 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. 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. 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. http://redemptionisland.survivor.com
  • 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. 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. Selecting a GCWith YG and OldGen being dealt withseparately we can now further selectdifferent GC algorithms. Factors:. Efficiency/Throughput. Pauses and Concurrency. Overhead
  • 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. 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. 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. InterGen ReferenceThere is extra effort involved to keep trackof references from OldGen to YG.. Card Tables, Dirty Markers etc
  • 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. Parallel GC in the YGSome JVM args-XX:+UseParallelGC-XX:ParallelGCThreads=<n>
  • 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. 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. 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. 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. 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. Memory sizingInitial and maximum heap size:-Xms6144m, -Xmx6144mPermGen size:-XX:MaxPermSize=256mYG size:-XX:NewSize=2500m, -XX:MaxNewSize=2500m
  • 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. 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. 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. 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. Tools
  • 36. Get in touchKai Koenig. Email: kai@ventego-creative.co.nz. Work: www.ventego-creative.co.nz. Blog: www.bloginblack.de. Twitter: @AgentK