JVM and Garbage Collection Tuning

JVM & GC Tuning Kai Koenig,Ventego Creative Ltd

Why?Reasons for tuning your JVM:. Growth vs. Resources. Performance issues. Error messages. Hardware scalability

Why?Typical issues:. Memory Leaks. Out-of-memory issues. Looooooooong Garbage Collection Pauses

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

http://www.ﬂickr.com/photos/museemccordmuseum/3294656277/

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

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

Old GenerationThe Old Generation ﬁlls 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

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 ﬁts into themain memory of the server. Rule of thumb: Avoid OldGen GCswhenever you can!

Typical examplesshort-lived:. Local variables/objects, iterators in a loopetcmedium-lived:. Session-based informationlong-lived:. Thread pools, singletons, frameworks

http://www.ﬂickr.com/photos/thomashawk/3958193579/

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

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 ﬁnd 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]

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.

http://redemptionisland.survivor.com

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

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. Efﬁciency?

Selecting a GCWith YG and OldGen being dealt withseparately we can now further selectdifferent GC algorithms. Factors:. Efﬁciency/Throughput. Pauses and Concurrency. Overhead

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

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

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

InterGen ReferenceThere is extra effort involved to keep trackof references from OldGen to YG.. Card Tables, Dirty Markers etc

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

Parallel GC in the YGSome JVM args-XX:+UseParallelGC-XX:ParallelGCThreads=<n>

OldGen CollectorsLots of objects, low mortality - Mark-and-Copy would be inefﬁcient: Mark-and-Compact.Variation of Mark-and-Sweep (reducedfragmentation). Quite involved: Marking, Calculation of newlocations, Reference Adjustments, Moving

OldGen CollectorsMark-and-Compact is expensive if we havelots of surviving objects and if we have alarge heap. Big downside: serial collector - stops allthreads

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

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)

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)

Memory sizingInitial and maximum heap size:-Xms6144m, -Xmx6144mPermGen size:-XX:MaxPermSize=256mYG size:-XX:NewSize=2500m, -XX:MaxNewSize=2500m

ExampleExtremely high-volume/trafﬁc 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

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

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

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

Get in touchKai Koenig. Email: kai@ventego-creative.co.nz. Work: www.ventego-creative.co.nz. Blog: www.bloginblack.de. Twitter: @AgentK

JVM and Garbage Collection Tuning

by Kai Koenig on Nov 17, 2011

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 1

Statistics

JVM and Garbage Collection Tuning Presentation Transcript