JAVA MEMORY MANAGEMENT

GARBAGE COLLECTION TUNING + SIZING MEMORY GENERATIONS

OVERVIEW

Theory and concepts:

JVM memory areas GC Tuning SAP standards HPJMeter JVMStat SAP Memory Analyser

Tools for logfile analysis

Case Study Discussion

JAVA VS C++
# include < string> int ma in ( int a rgc, cha r ** a rgv) { int i; string * va r; for (i = 0; i < 1000; i + + ) { va r = ne w string (me mory le a king or not); de le te (va r); } }

JAVA VS C++
import ja va .la ng.String; public sta tic void ma in ( String [] a rgume nts) { int i; String va r; for (i = 0; i < 1000; i + + ) { va r = ne w String (me mory ne ve r le a king); } }

TOWARDS HOTSPOT JVM

HOTSPOT JVM

HOW DOES GC WORK

HOW DOES GC WORK

HOW DOES GC WORK

HOW DOES GC WORK

GC LOGGING

-verbose:gc
[GC 325407K->83000K(776768K), 0.2300771 secs]

[GC 325816K->83372K(776768K), 0.2454258 secs]

[Full GC 267628K->83769K(776768K), 1.8479984 secs]

-XX:+PrintGCDetails
[GC [DefNew: 64575K->959K(64576K), 0.0457646 secs] 196016K>133633K(261184K), 0.0459067 secs]]

-XX:+PrintGCTimeStamps 111.042: [GC 111.042: [DefNew: 8128K->8128K(8128K), 0.0000505 secs]111.042: [Tenured: 18154K->2311K(24576K), 0.1290354 secs] 26282K->2311K(32704K), 0.1293306 secs]

Logfile:

GC LOGGING

-XX:+PrintTenuringDistribution 1096.789: [GC 1096.789: [ParNew Desired survivor size 86232268 bytes, new threshold 6 (max 12) - age 1: 50754696 bytes, 50754696 total - age 2: 12147696 bytes, 62902392 total

- age 3: 12295552 bytes, 75197944 total

-age 4: 6537136 bytes, 81735080 total - age 5: 2435944 bytes, 84171024 total - age 6: 3013488 bytes, 87184512 total

- age 7: 627368 bytes, 87811880 total

- age 8: 999536 bytes, 88811416 total - age 9: 924656 bytes, 89736072 total - age 10: 1811480 bytes, 91547552 total

: 554848K->89528K(561792K), 0.5317388 secs] 607743K->146164K(1217152K) icms_dc=18 , 0.5326526 secs]

PERFORMANCE CONCEPTS

TROUGHPUT: % of runtime in GC
PAUSE FOOTPRINT PROMPTNESS

GC DESIGN

SERIAL vs PARALLEL
CONCURRENT vs STOPTHEWORLD COMPACTING vs NONCOMPACTING vs COPYING

FOUR GARBAGE COLLECTORS

Default Collector
-XX:+UseParallelGC -XX:UseConcMarkSweepGC -Xincgc

DEFAULT GC

Single Thread
Stop the World

PARALLEL GC

Minor collections only

+2 Processor machines -> Overhead Fragmentation Tenured generation Stop the World Full GC -> Performance Trap -XX:ParallelGCThreads=<nr>

CONCURRENT

Parallel Minor GC
Concurrent Full GC Fragmentation

Minors during Full Collections

Memory + resource intensive -> free thread Future to overcome Performance Trap Large Tenured Generation High Troughput, low pauses, lower footprint, better promptness

TUNING GUIDELINES

Use tools to get an idea of the applications lifetime distribution ++ objects alive during GC = longer pauses Young Generation Guarantee ++ Eden space and Survivor spaces:

Fast collection because more dead object Less collections does not equal longer pauses Less copying Less often full collections + faster full collections

More processors = more memory needed (esp Eden) Set memory sizes optimal, test a GC, retune memory sizes

Performance trap non scalability of JVM

SAP SETTINGS
Sapnote 723909 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:NewSize = -XX:MaxNewSize -XX:PermSize = -XX:MaxPermSize (256m 512m) -Xms = -Xmx = 2048 MB (170m Dispatcher + 50m per extra server) -XX:NewSize = 1/6 Xmx (1/3 Dispatcher) -Xss2m -XX:SurvivorRatio=2 -XX:TargetSurvivorRatio=90 -XX:+UseParNewGC -XX:+PrintTenuringDistribution -XX:MaxTenuringThreshold=31 -XX:+UseTLAB -XX:+UseConcMarkSweepGC -XX:DisableExplicitGC