View
242
Download
0
Embed Size (px)
Citation preview
uPortal Performance Optimization
Faizan AhmedArchitect and Engineering GroupEnterprise Systems & [email protected]
04/21/23 2
GC History Garbage Collection (GC) has been
around for a while (1960’s LISP, Smalltalk, Eiffel, Haskell, ML, Scheme and Modula-3)
Went mainstream in the 1990’s with Java (then C#)
JVM implementations have improved on GC algorithms/speed over the past decade
04/21/23 3
GC Benefits/Cost Benefits
Increased reliability Decoupling of memory mgmt from program
design Less time spent debugging memory errors Dangling points/memory leaks do not occur
(Note: Java programs do NOT have memory leaks; “unintentional object retention” is more accurate)
Costs Length of GC pause CPU/memory utilization
04/21/23 4
GC Options
Sun’s 1.3 JDK included 3 GC strategies
1.4 JDK includes 6 and over a dozen command line options
Application type will demand strategy: Real-time – short and bounded pauses Enterprise – may tolerate longer or less
predictable pauses in favor of higher throughput
04/21/23 5
GC Phases
GC has two main phases: Detection Reclamation
Steps are either distinct: Mark-Sweep, Mark-Compact
… or interleaved Copying
04/21/23 6
Fundamental GC Property
“When an object becomes garbage, it stays garbage.”
04/21/23 7
Reachability
Roots – reference to object in a static variable or local variable on an active stack frame
Root Objects – directly reachable from roots
Live Objects – all objects transitively reachable from roots
Garbage Objects – all other objects
04/21/23 8
Reachability Example
RuntimeStack
ref
ref
Heap
04/21/23 9
GC Algorithms
Two basic approaches: Reference Counting – keep a count of
references to an object; when a count of zero, object is garbage
Tracing – trace out the graph of objects starting from roots and mark; when complete, unmarked objects are garbage
04/21/23 10
Reference Counting
An early GC strategy Advantages:
can be run in small chunks of time Disadvantages:
does not detect cycles overhead in incrementing/decrementing
counters Reference Counting is currently out-of
favor
04/21/23 11
Tracing
Basic tracing algorithm is known as mark and sweep mark phase – GC traverses reference
tree, marking objects sweep phase – umarked objects are
finalized/freed
04/21/23 12
Mark-Sweep Example
Root
1. mark-sweep start
Root
2. end of marking
Root
3. end of sweeping
04/21/23 13
Mark-Sweep
Problem is fragmentation of memory Two strategies include:
Mark-Compact Collector – After mark, moves live objects to a contiguous area in the heap
Copy Collector – moves live objects to a new area
04/21/23 14
Mark-Compact Collector Example
Root
1. end of marking
Root
2. end of compacting
04/21/23 15
Copy Collector Example
Root
1. copying start
Root
2. end of copying
UnusedUnused
UnusedUnused
From
From
To
To
04/21/23 16
Performance Characteristics
Mark-Compact collection is roughly proportional to the size of the heap
Copy collection time is roughly proportional to the number of live objects
04/21/23 17
Copying
Advantages: Very fast…if live object count is low No fragmentation Fast allocation
Disadvantages: Doubles space requirements – not
practical for large heaps
04/21/23 18
Observations
Two very interesting observations: Most allocated objects will die young Few references from older to younger
objects will exist These are known as the weak
generational hypothesis
04/21/23 19
Generations
Heap is split into generations, one young and one old Young generation – all new objects are
created here. Majority of GC activity takes place here and is usually fast (Minor GC).
Old generation – long lived objects are promoted (or tenured) to the old generation. Fewer GC’s occur here, but when they do, it can be lengthy (Major GC).
04/21/23 20
Sun HotSpot Heap Layout
Young Old Permanent
Eden From To
Survivor Spaces
04/21/23 21
Before Minor GC
Old Permanent
Eden From To
Survivor Spaces
UnusedUnused
Young
04/21/23 22
After Minor GC
EmptyEmpty
Old Permanent
Eden To From
Survivor Spaces
UnusedUnused
Young
04/21/23 23
GC Notes
Algorithm used will vary based on VM type (e.g., client/server)
Algorithm used varies by generation Algorithm defaults change between
VM releases (e.g., 1.4 to 1.5)
04/21/23 24
Young Generation Collectors Serial Copying Collector
All J2SEs (1.4.x default) Stop-the-world Single threaded
Parallel Copying Collector -XX:+UseParNewGC JS2E 1.4.1+ (1.5.x default) Stop-the-world Multi-threaded
Parallel Scavenge Collector -XX:UseParallelGC JS2E 1.4.1+ Like Parallel Copying Collector Tuned for very large heaps (over 10GB) w/ multiple CPUs Must use Mark-Compact Collector in Old Generation
04/21/23 25
Serial vs. Parallel Collector
stop-the-worldpause
SerialCollector
ParallelCollector
04/21/23 26
Old Generation Collectors Mark-Compact Collector
All J2SEs (1.4.x default) Stop-the-world Single threaded
Train (or Incremental) Collector -Xincgc About 10% performance overhead All J2SEs To be replaced by CMS Collector
Concurrent Mark-Sweep (CMS) Collector -XX:+UseConcMarkSweepGC J2SE 1.4.1+ (1.5.x default (-Xincgc)) Mostly concurrent Single threaded
04/21/23 27
Mark-Compact vs. CMS Collector
stop-the-worldpause
Mark-CompactCollector
Concurrent Mark-SweepCollector
initial mark
concurrentmarking
remark
concurrent sweeping
04/21/23 28
JDK 1.4.x Heap Option Summary
Low Pause Collectors Throughput Collectors Heap SizesGeneration
Young
Old
Permanent
1 CPU 2+ CPUs
Serial Copying Collector (default)
Parallel Copying Collector
-XX:+UseParNewGC
1 CPU 2+ CPUs
Copying Collector (default)
Parallel Scavenge Collector
-XX:+UseParallelGC-XX:+UseAdaptiveSizePolicy
-XX:+AggressiveHeap
-XX:NewSize-XX:MaxNewSize
-XX:SurvivorRatio
Mark-Compact Collector (default)
Concurrent Collector
-XX:+UseConcMarkSweepGC
Mark-Compact Collector (default)
Mark-Compact Collector (default)
-Xms-Xmx
Can be turned off with –Xnoclassgc (use with care)-XX:PermSize
-XX:MaxPermSize
04/21/23 29
Heap Tuning
Analyze application under realistic load
Run with –verbose:gc and other options to identify GC information
Select GC engine based on need Size areas of heap based on
application profile – e.g., an app that creates many temporary objects may need a large eden area
04/21/23 30
Verbose Minor GC Example62134.872: [GC {Heap before GC invocations=1045:Heap def new generation total 898816K, used 778761K eden space 749056K, 100% used from space 149760K, 19% used to space 149760K, 0% used tenured generation total 1048576K the space 1048576K, 24% used compacting perm gen total 32768K, used 26906K the space 32768K, 82% used62134.880: [DefNewDesired survivor size 138018816 bytes, new threshold 16 (max 16)- age 1: 3718312 bytes, 3718312 total- age 2: 5935096 bytes, 9653408 total- age 3: 2614616 bytes, 12268024 total- age 4: 1426056 bytes, 13694080 total- age 5: 2095808 bytes, 15789888 total- age 6: 3996288 bytes, 19786176 total- age 7: 550448 bytes, 20336624 total- age 8: 4058384 bytes, 24395008 total: 778761K->23823K(898816K), 0.1397140 secs] 1035112K->280173K(1947392K) Heap after GC invocations=1046:Heap def new generation total 898816K, used 23823K eden space 749056K, 0% used from space 149760K, 15% used to space 149760K, 0% used tenured generation total 1048576K, used 256350K the space 1048576K, 24% used compacting perm gen total 32768K, used 26906K the space 32768K, 82% used} , 0.1471464 secs]
04/21/23 31
Verbose Major GC Example199831.706: [GC {Heap before GC invocations=9786:Heap def new generation total 898816K, used 749040K eden space 749056K, 99% used from space 149760K, 0% used to space 149760K, 0% used tenured generation total 1048576K, used 962550K the space 1048576K, 91% used compacting perm gen total 32768K, used 27040K the space 32768K, 82% used199831.706: [DefNew: 749040K->749040K(898816K), 0.0000366 secs]199831.707:
[Tenured: 962550K->941300K(1048576K), 3.6172827 secs] 1711590K->1653534K(1947392K) Heap after GC invocations=9787:
Heap def new generation total 898816K, used 712233K eden space 749056K, 95% used from space 149760K, 0% used to space 149760K, 0% used tenured generation total 1048576K, used 941300K the space 1048576K, 89% used compacting perm gen total 32768K, used 27007K the space 32768K, 82% used} , 3.6185589 secs]
04/21/23 32
04/21/23 33
Demonstrate Heap tuning
JVM heap tuning was demonstrated for uPortal running on local machine using JDK 1.5.06 . (one hour)
04/21/23 34
Programming Tips No need to call System.gc() Finalizers must be used with care! The use of Object pools can be debated Learn to use ThreadLocal for large Objects
(but use with care) Be cognizant of the number/size of Objects
being created Use caches judiciously (e.g.,
WeakHashMap’s make bad caches under a heavily loaded system)
04/21/23 35
Techniques for production env.
lsof command File descriptors Verbose gc Kill -3 Tune gc
04/21/23 36
Conclusions
GC can be your friend (or enemy) Put your app on an Object diet Should always monitor an app with -
verbose:gc -XX:+PrintGCDetails Tune your heap only if there is a
problem A large heap may slow an app (more
memory is not always good)
04/21/23 37
??????????
04/21/23 38
References
Garbage Collection in Java - http://www.cs.usm.maine.edu/talks/05/printezis.pdf
A brief history of garbage collection – http://www-128.ibm.com/developerworks/java/library/j-jtp10283/
Garbage collection in the HotSpot JVM - http://www-128.ibm.com/developerworks/java/library/j-jtp11253/
Diagnosing a GC problem -
http://java.sun.com/docs/hotspot/gc1.4.2/example.html