UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems &...
-
date post
20-Jan-2016 -
Category
Documents
-
view
238 -
download
0
Transcript of UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems &...
![Page 1: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/1.jpg)
uPortal Performance Optimization
Faizan AhmedArchitect and Engineering GroupEnterprise Systems & [email protected]
![Page 2: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/2.jpg)
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
![Page 3: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/3.jpg)
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
![Page 4: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/4.jpg)
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
![Page 5: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/5.jpg)
04/21/23 5
GC Phases
GC has two main phases: Detection Reclamation
Steps are either distinct: Mark-Sweep, Mark-Compact
… or interleaved Copying
![Page 6: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/6.jpg)
04/21/23 6
Fundamental GC Property
“When an object becomes garbage, it stays garbage.”
![Page 7: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/7.jpg)
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
![Page 8: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/8.jpg)
04/21/23 8
Reachability Example
RuntimeStack
ref
ref
Heap
![Page 9: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/9.jpg)
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
![Page 10: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/10.jpg)
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
![Page 11: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/11.jpg)
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
![Page 12: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/12.jpg)
04/21/23 12
Mark-Sweep Example
Root
1. mark-sweep start
Root
2. end of marking
Root
3. end of sweeping
![Page 13: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/13.jpg)
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
![Page 14: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/14.jpg)
04/21/23 14
Mark-Compact Collector Example
Root
1. end of marking
Root
2. end of compacting
![Page 15: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/15.jpg)
04/21/23 15
Copy Collector Example
Root
1. copying start
Root
2. end of copying
UnusedUnused
UnusedUnused
From
From
To
To
![Page 16: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/16.jpg)
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
![Page 17: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/17.jpg)
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
![Page 18: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/18.jpg)
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
![Page 19: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/19.jpg)
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).
![Page 20: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/20.jpg)
04/21/23 20
Sun HotSpot Heap Layout
Young Old Permanent
Eden From To
Survivor Spaces
![Page 21: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/21.jpg)
04/21/23 21
Before Minor GC
Old Permanent
Eden From To
Survivor Spaces
UnusedUnused
Young
![Page 22: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/22.jpg)
04/21/23 22
After Minor GC
EmptyEmpty
Old Permanent
Eden To From
Survivor Spaces
UnusedUnused
Young
![Page 23: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/23.jpg)
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)
![Page 24: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/24.jpg)
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
![Page 25: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/25.jpg)
04/21/23 25
Serial vs. Parallel Collector
stop-the-worldpause
SerialCollector
ParallelCollector
![Page 26: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/26.jpg)
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
![Page 27: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/27.jpg)
04/21/23 27
Mark-Compact vs. CMS Collector
stop-the-worldpause
Mark-CompactCollector
Concurrent Mark-SweepCollector
initial mark
concurrentmarking
remark
concurrent sweeping
![Page 28: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/28.jpg)
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
![Page 29: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/29.jpg)
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
![Page 30: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/30.jpg)
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]
![Page 31: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/31.jpg)
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]
![Page 32: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/32.jpg)
04/21/23 32
![Page 33: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/33.jpg)
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)
![Page 34: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/34.jpg)
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)
![Page 35: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/35.jpg)
04/21/23 35
Techniques for production env.
lsof command File descriptors Verbose gc Kill -3 Tune gc
![Page 36: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/36.jpg)
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)
![Page 37: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/37.jpg)
04/21/23 37
??????????
![Page 38: UPortal Performance Optimization Faizan Ahmed Architect and Engineering Group Enterprise Systems & Services RUTGERS faizan@rutgers.edu@rutgers.edu.](https://reader035.fdocuments.in/reader035/viewer/2022081723/56649d435503460f94a1ebf8/html5/thumbnails/38.jpg)
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