Die Präsentation behandelt die Grundlagen von Java-Anwendungen und der Java Virtual Machine (JVM) für den Betrieb (Ops), wobei der Fokus auf den Unterschieden zwischen Entwicklungs- und Betriebsumgebungen gelegt wird. Themen wie Garbage Collection, Speicherverwaltung, JVM-Optimierung und das Monitoring von Java-Anwendungen mittels JMX und Java Flight Recorder werden behandelt, um eine effektive Fehlerdiagnose und Performance-Optimierung zu ermöglichen. Abschließend wird betont, dass eine enge Zusammenarbeit zwischen Entwicklung und Betrieb für den Erfolg von Java-Anwendungen entscheidend ist.

1. Brownbag:
Java Applikationen
und die JVM für “Ops”
Christian Rohmann Köln, 28.04.2017
1

2. Bei inovex seit Januar 2017
Standort: Köln
2
Christian Rohmann
LoB ITO - Systems Engineer Linux

3. › Grundlagen - Java und JVM
› Garbage Collection / Tuning
› JMX - Java Management Extensions
› Heap- / Thread Dumps
› Java Flight Recorder / Java Mission Control
3Java Applikationen und die JVM für “Ops”
Agenda
Was muss ich mir für die Pizza alles anhören?

4. › Klare Trennung der Zuständigkeiten?
› Java Code = Dev
› Java Runtime = Ops
› Spoiler: Nein!
4Java Applikationen und die JVM für “Ops”
Java Code and Java Runtime
“DevOps” as obvious as it gets

5. › (Java) Code wird in Bytecode kompiliert
› architektur-spezifische JavaVM -
“write once - run anywhere”
› Mehr als eine JVM (Oracle, OpenJDK, IBM, HP, …)
› HotSpot / JIT
› Bytecode -> Machine code / system calls
› Optimierung zur Laufzeit
› Memory Management automagisch
› Kein malloc(), kein free(), dafür Garbage Collection
5Java Applikationen und die JVM für “Ops”
Die Java Virtual Machine
The machine inside the machine (inside the machine)

6. › Security - SSL/Crypto libs sind in JVM“eingebaut”
* Bug Fix: Remove TrustCenter CA
* RC4 cipher suites have been removed from both client and server default enabled cipher suite
list in Oracle JSSE implementation
* Increase the minimum key length to 1024 for XML Signatures
* Correction of IllegalArgumentException from TLS handshake
› Abstraktion vom OS und dessen Updates
* JDK 8u51 contains IANA time zone data version 2015d
› Änderungen von defaults
* The default value for G1HeapWastePercent was changed from 10 to 5 to reduce the
need for full GCs. For the same reason the default value for G1MixedGCLiveThresholdPercent
was changed from 65 to 85.
6Java Applikationen und die JVM für “Ops”
Die Java Virtual Machine
Dev vs. Ops - JVM (minor) Updates ...

7. › Take away: JVM Updates = (security) patches
› Java Expiration Date: The expiration date for 8u121 is April 18, 2017. Java
expires whenever a new release with security vulnerability fixes becomes available.
› https://www.java.com/en/download/faq/release_changes.xml
› Parameter für Oracle JVM 8 (> 830)
› Take away: -XX:+PrintFlagsFinal
› Umstieg auf Java 8 / Java 9
› Code vs. JVM
7Java Applikationen und die JVM für “Ops”
Die Java Virtual Machine
Dev vs. Ops

8. 8Java Applikationen und die JVM für “Ops”
JVM Heap Space
In der x-ten Generation
Quelle: https://de.wikipedia.org/wiki/Garbage_Collection

9. › Generational Garbage Collection
› “Eden” und “Survivors” - Young generation
› “Tenured” - Old generation
› JVM verwaltet Speicher
› Limits: -XX:InitialHeapSize // -XX:MaxHeapSize
› Take away: Xms = Xmx
› Take away: Xmx ist NICHT das Limit für dem JVM-Prozess
9Java Applikationen und die JVM für “Ops”
JVM Heap Space
Ein großer Haufen … Speicher

10. › GC konkurriert mit Applikation
› CPU cycles und hard real time (STW - GC pause)
› Unterschiedliche Implementierungen
(1. Serial - 1 Thread / CPU core )
2. Parallel bzw. Throughput (Multi-Threaded, wie viele?)
3. Concurrent-Mark-Sweep - CMS
4. G1 - Garbage First
› Teils mit (unendlich) vielen Optionen / Tuning-Parametern
› Auto-tuning (-XX:MaxGCPauseMillis / -XX:GCTimeRatio)
› Ergonomics (Anzahl CPU-cores, NUMA, TLAB, … )
10Java Applikationen und die JVM für “Ops”
JVM Garbage Collection
Ich dachte es kümmert sich einer™ drum …

11. -XX:CMSTriggerPermRatio=80
-XX:CMSFullGCsBeforeCompaction=1
-XX:+ParallelRefProcEnabled
-XX:+CMSParallelRemarkEnabled
-XX:CMSMaxAbortablePrecleanTime=6000
-XX:CMSInitiatingOccupancyFraction=50
-XX:+UseCMSInitiatingOccupancyOnly
-XX:PretenureSizeThreshold=64m
-XX:+CMSScavengeBeforeRemark
-XX:ParallelGCThreads=6
-XX:ConcGCThreads=6
-XX:+UseParNewGC
-XX:+UseConcMarkSweepGC
-XX:MaxTenuringThreshold=8
-XX:TargetSurvivorRatio=90
-XX:SurvivorRatio=4
-XX:NewRatio=2
11Java Applikationen und die JVM für “Ops”
GC für eine Applikation tunen
How hard can it be?

12. 12Java Applikationen und die JVM für “Ops”
JVM Garbage Collection
Wer bringt nun den Müll raus?
Young collector Old collector JVM option
Serial (DefNew) Serial Mark-Sweep-Compact -XX:+UseSerialGC
Parallel scavenge (PSYoungGen) Serial Mark-Sweep-Compact (PSOldGen) -XX:+UseParallelGC
Parallel scavenge (PSYoungGen) Parallel Mark-Sweep-Compact (ParOldGen) -XX:+UseParallelOldGC
Serial (DefNew) Concurrent Mark Sweep -XX:+UseConcMarkSweepGC
-XX:-UseParNewGC
Parallel (ParNew) Concurrent Mark Sweep -XX:+UseConcMarkSweepGC
-XX:+UseParNewGC
G1 -XX:+UseG1GC
Quelle: http://blog.ragozin.info/2011/09/hotspot-jvm-garbage-collection-options.html

13. 13Java Applikationen und die JVM für “Ops”
Strategien der GC Implementierungen
13
Quelle: http://www.techpaste.com/2012/02/java-garbage-collectors-gc/

14. › (Maximum) Pause Time
› Stop-The-World = Benutzer wartet
› Throughput
› garbage collection time vs. application time
› BigData / Batch / non-realtime
› Footprint
› microservices / horizontale Skalierung
› Gory Details zu JVM GC in der
Brownbag “Java-Optimierung” von Daniel Bäurer
14Java Applikationen und die JVM für “Ops”
Optimierungsziele für GC
Classic “pick two” (or less)

15. › JVM GC hat signifikante Auswirkungen auf die
Applikations-Performance
› Stop-The-World (STW)
› Anpassungen an HW (GC threads, NUMA, …)
15Java Applikationen und die JVM für “Ops”
Java Code vs. Java Runtime
Why should I (T Operations) care?

16. Take away ------------------>
-XX:+PrintGC
-XX:+PrintGCDetails
-XX:+PrintGCCause
-XX:+PrintHeapAtGC
-XX:+PrintGCDateStamps
-XX:+PrintGCApplicationStoppedTime
-XX:+PrintGCApplicationConcurrentTime
-XX:+PrintTenuringDistribution
-XX:+PrintAdaptiveSizePolicy
-Xloggc:/logs/jvm_gc.log
-XX:+UseGCLogFileRotation
-XX:GCLogFileSize=100M
-XX:NumberOfGCLogFiles=5
16Java Applikationen und die JVM für “Ops”
JVM Garbage Collection Logging
Warum ist was passiert?
Quelle: https://www.slideshare.net/leonjchen/java-gc-javadeveloperdaytw/36

17. › Korrelation zu anderen Metriken
› Dynamic bzgl. traffic, Requests/s, …
› 99%-lie
› Log Format ist unstrukturiert und GC-spezifisch
› Netflix gcviz / LinkedIn naarad
› G1 oft (noch) nicht unterstützt
› Parser as a Service:
› GCEasy (http://gceasy.io/)
› GCPlot (https://gcplot.com/)
› jClarity Censum (https://www.jclarity.com/censum/)
17Java Applikationen und die JVM für “Ops”
GC Logs auswerten / visualisieren
Wo ist mein Elch?

18. › Ein kleiner, open-source Lichtblick
URL: https://github.com/chewiebug/GCViewer
18Java Applikationen und die JVM für “Ops”
GC Logs auswerten / visualisieren
GCViewer

19. › OOM tötet … oder auch nicht
› Take away: -XX:OnOutOfMemoryError="kill -9 %p"
› GC overhead limit exceeded
› Mehr als 98% der Zeit in GC und < 2% recovered
› Take away: Meist nur der heap zu klein
› Automatischer Heap Dump bei OOM
› Take away:
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=<path>
19Java Applikationen und die JVM für “Ops”
Was tun wenns trotzdem kracht?
Nach dem OOM ist vor dem OOM ...

20. › Post-Mortem bei OOM
› Jederzeit sonst!
› Unerlässlich auch bei kommerzieller Software!
› Analyse durch Hersteller
› Heap-Dump mit JVM Bordmitteln
› Take away:
jcmd <process id/main class> GC.heap_dump filename=heap.hprof
jmap -dump:format=b,file=heap.hprod pid
20Java Applikationen und die JVM für “Ops”
Heapdumps
Ja, wo laufen sie denn ...

21. › Heap-Dump mit GDB
› Take away:
gdb –pid=$JVM_PID
(gdb) gcore /tmp/jvm.core
Saved corefile /tmp/jvm.core
(gdb) detach
(gdb) quit
...
› Liste aller Threads und ihrer Status
› Take away: kill -3 $jvm_pid
› Output nach STDOUT
21Java Applikationen und die JVM für “Ops”
und Threaddumps
… wo laufen sie denn hin?
...
jmap
-dump:format=b,file=jvm.hprof
/usr/bin/java /tmp/jvm.core

22. › MBeans
› Metriken (z.B. Prometheus JMX Exporter)
› Operationen (GC auslösen, Settings ändern)
› Notifications
› Das “SNMP” der JVM
› Eigener TCP-Port
› TLS + Authentication
› JVM liefert viele Standard MBeans (z.B. GC)
› Applikationen, können und sollten selber MBeans
mitliefern!
22Java Applikationen und die JVM für “Ops”
JMX - Java Management Extensions
Der Diagnosestecker für die JVM (und die Applikation)

23. › JVM live analysieren
› Threads
› Locks
› Memory
› Heap Dumps laden
› Plugins wie z.B. VisualGC
URL: Teil von OracleJDK oder https://visualvm.github.io/
23
VisualVM
All-in-One Java Troubleshooting Tool
Java Applikationen und die JVM für “Ops”

24. › Post-Mortem-Analyze
von Heap Dumps
› Statistiken
› Drilldowns
URL: http://www.eclipse.org/mat/
24
Eclipse - Memory Analyzer Tool
Fast and feature-rich Java heap analyzer
Java Applikationen und die JVM für “Ops”

25. › Event Recorder “for collecting diagnostic and profiling data
about a running Java application [...] performance impact is
less than one percent”
› Ergänzung zu (teuren) APM Tools wie
New Relic / Dynatrace / AppDynamics
› ab JDK 7u40 verfügbar
› Nur in Oracle JDK
› In Produktion Oracle Java Lizenz erforderlich
25
Java Flight Recorder (JFR)
Die Black Box gegen die (JVM-)Blackbox
Java Applikationen und die JVM für “Ops”

26. › JFR per Command Line Option aktivieren
-XX:+UnlockCommercialFeatures
-XX:+FlightRecorder
› ad-hoc recording
jcmd $jvm_pid JFR.start duration=600s filename=myrecording.jfr
› dauerhaft mitschreiben
-XX:FlightRecorderOptions=defaultrecording=true,disk=true,
repository=/tmp/jfr,
dumponexit=true,
dumponexitpath=/var/log/jfr/ ,
maxage=48h,
maxsize=2G,
settings=default
26
Java Flight Recorder (JFR)
Die Black Box gegen die (JVM-)Blackbox
Java Applikationen und die JVM für “Ops”

27. › Teil der Tools des Oracle JDK
› Entstammt der JRockit VM
› Analyse live oder mittels JFR recordings
URL: http://oracle.com/missioncontrol
27
Java Mission Control
Houston - Wo ist das Problem?
Java Applikationen und die JVM für “Ops”

28. › Java gibts nicht ohne JVM
› “Write once, run anywhere” …. but how (well)?
“Bei so viel Automatik sind Mechanismen zum Monitoring und Performance-Tuning von
Anwendungen sehr wichtig. Im Fehlerfall oder bei ungenügender Performance soll die
Ursache schnell und sicher ermittelbar und idealerweise durch gezieltes Tuning
korrigierbar sein.” - codecentric Blog
28
Fazit
Java und JVM sind wie Dev und Ops
Java Applikationen und die JVM für “Ops”

29. Vielen Dank
Christian Rohmann
Systems Engineer Linux
Kupferhütte 4.1
Schanzenstraße 6-20
51063 Köln
christian.rohmann@inovex.de
29