210 likes | 300 Views
Power your JVM with Effective Garbage Collection Tuning. SiliconIndia Java Conference 29 th October, 2010 Vivekanand Jha. Its Science. Measure>Understand>>Tune>>Measure>>Understand>>Retune …. Agenda. Some background on JVM GC Architecture Demystifying JVM tuning and GC tuning
E N D
Power your JVM with Effective Garbage Collection Tuning SiliconIndia Java Conference 29th October, 2010 Vivekanand Jha
Its Science Measure>Understand>>Tune>>Measure>>Understand>>Retune ….
Agenda • Some background on JVM GC Architecture • Demystifying JVM tuning and GC tuning • Reading the logs
GC in JDK 7 & other exotic GC algorithms • G1 or Garbage first algorithm, the holy grail of Garbage collection? • Pauseless garbage collection from Azul. • Garbage collection with hard time guarantee in Sun’s premium product JAVA RTS
GC Tuning • Tuning the Young Generation • Tuning Parallel GC • Tuning CMS • Monitoring GC
Dream GC • Low GC Overhead. ie. High Throughput • Low GC pause times • Space efficiency (Less fragmentation)
Wisdom droplets • Supersize it • Minimize live object for minor collections • Size the Tenured generation to steady state space requirement • WHEN IN DOUBT, SUPERSIZE IT!!
Unnecessary Information • -Xmx<size> : max heap size • ● young generation + old generation • > -Xms<size> : initial heap size • ● young generation + old generation • > -Xmn<size> : young generation size • > Applications with emphasis on performance tend • to set -Xms and -Xmx to the same value • > When -Xms != -Xmx, heap growth or shrinking • requires a Full GC
How to get your object profile in YG • Monitor tenuring distribution with -XX:+PrintTenuringDistribution • Desired survivor size 6684672 bytes, new threshold 8 (max 8) - age 1: 2315488 bytes, 2315488 total - age 2: 19528 bytes, 2335016 total - age 3: 96 bytes, 2335112 total - age 4: 32 bytes, 2335144 total
CMS-Too early [ParNew 390868K->296358K(773376K), 0.1882258 secs] [CMS-initial-mark 298458K(773376K), 0.0847541 secs] [ParNew 401318K->306863K(773376K), 0.1933159 secs] [CMS-concurrent-mark: 0.787/0.981 secs] [CMS-concurrent-preclean: 0.149/0.152 secs] [CMS-concurrent-abortable-preclean: 0.105/0.183 secs] [CMS-remark 374049K(773376K), 0.0353394 secs] [ParNew 407285K->312829K(773376K), 0.1969370 secs] [ParNew 405554K->311100K(773376K), 0.1922082 secs] [ParNew 404913K->310361K(773376K), 0.1909849 secs] [ParNew 406005K->311878K(773376K), 0.2012884 secs] [CMS-concurrent-sweep: 2.179/2.963 secs] [CMS-concurrent-reset: 0.010/0.010 secs] [ParNew 387767K->292925K(773376K), 0.1843175 secs] [CMS-initial-mark 295026K(773376K), 0.0865858 secs] [ParNew 397885K->303822K(773376K), 0.1995878 secs]
CMS-Too Late [ParNew 742993K->648506K(773376K), 0.1688876 secs] [ParNew 753466K->659042K(773376K), 0.1695921 secs] [CMS-initial-mark 661142K(773376K), 0.0861029 secs] [Full GC 645986K->234335K(655360K), 8.9112629 secs] [ParNew 339295K->247490K(773376K), 0.0230993 secs] [ParNew 352450K->259959K(773376K), 0.1933945 secs]
-XX:+ExplicitGCInvokesConcurrent Requires a post 6 JVM -XX:+ExplicitGCInvokesConcurrentAndUnloadClasses
Monitoring GC You need at least: ● -XX:+PrintGCTimeStamps (Add -XX:+PrintGCDateStamps if you must) ● -XX:+PrintGCDetails Preferred over -verbosegc as it's more detailed > Also useful: ● -Xloggc:<file> Separates GC logging output from application output