Java Application Memory Usage and Analysis

The Java Virtual Machine (JVM) runs standalone applications and many key enterprise applications like monolithic application servers, API Gateways and microservices. Understanding an tuning an application begins with understanding the technology running it. Here is a quick overview of the JVM Memory management

JVM Memory:

Stack and Heap form the memory used by a Java Application
The execution thread uses the Stack – it starts with the ‘main’ function and the functions it calls along with primitives they create and the references to objects in these functions
All the objects live in the Heap – the heap is bigger
Stack memory management (cleaning old unused stuff) is done using a Last In First Out (LIFO) strategy
Heap memory management is more complex since this is where objects are created and cleaning them up requires care
You use command line (CLI) arguments to control sizes and algorithms for managing the Java Memory

Java Memory Management:

Memory management is the process of cleaning up unused items in Stack and Heap
Not cleaning up will eventually halt the application as the fixed memory is used up and an out-of-memory or a stack-overflow exception occurs
The process of cleaning JVM memory is called “Garbage Collection” a.k.a “GC”
The Stack is managed using a simple LIFO strategy
The Heap is managed using one or more algorithms which can be specified by Command Line arguments
The Heap Collection Algorithms include Serial, New Par, Parallel Scavenge, CMS, Serial Old (MSC), Parallel Old and G1GC

I like to use the “Fridge” analogy – Think about how leftovers go into the fridge and how last weeks leftovers, fresh veggies and that weird stuff from long long ago gets cleaned out … what is your strategy? JVM Garbage Collection Algorithms follow a similar concept while working with a few more constraints (how do you clean the fridge while your roommate/partner/husband/wife is/are taking food out?)

Java Heap Memory:

The GC Algorithms divide the heap into age based partitions
The process of cleanup or collection uses age as a factor
The two main partitions are “Young or New Generation” and “Old or Tenured Generation” space
The “Young or New Generation” space is further divided into 2 Survivor partitions
Each survivor partition is further divided into multiple sections based on command line arguments
We can control the GC Algorithm performance based on our use-case and performance requirements through command line arguments that specify the size of the Young, Old and Survivor spaces.

For example, consider applications that do not have long lived objects – Stateless web applications, API Gateway products e.t.c … these need larger Young or New Generation space with a strategy to age objects slowly (long tenuring). These would use either the NewPar GC or CMS algorithm to do Garbage Collection – if there are more than 2 CPU cores available (i.e. extra threads for the collector) then the application can benefit more with the CMS algorithm

The Picture Below give a view of how the Heap section of the Java Application’s memory is divided. There are partitions based on the age of “Objects” and stuff that is very old and unused eventually gets cleaned up

JVM Heap.png

The Heap and Stack Memory can be viewed at runtime using various tools like Oracle’s JRockit Mission Control (now part of the JDK), we can also do very long term analysis of the memory and the garbage collection process using Garbage Collection (GC) logs and free tools to parse GC logs

One of the key resources to analyse in the JVM is the Memory usage and Garbage Collection. The process of cleaning un-used objects from the JVM memory is called “Garbage Collection (GC)”, details of how this works is provided here: Java Garbage Collectors

Tools:

Oracle JRockit Mission Control is now free with the JDK!

OSX : “/Library/Java/JavaVirtualMachines/{JDK}/Contents/Home/bin/”
Windows: “JDK_HOME/bin/”

GC Viewer tool can be downloaded from here

https://github.com/chewiebug/GCViewer

Memory Analysis Tools:

Runtime memory analysis with Oracle JRockit Mission Control (JMRC)
Garbage Collection (GC) logs and “GC Viewer Tool” analyser tool

Oracle JRockit Mission Control (JMRC)

Available for SPARC, Linux and Windows only
Download here: http://www.oracle.com/technetwork/java/javase/downloads/java-archive-downloads-jrockit-2192437.html
Usage Examples:
High Level CPU and Heap usage, along with details on memory Fragmentation
Detailed view of Heap – Tenured, Young Eden, Young Survivor etc
The “Flight Recorder” tool helps start a recording session over a duration and is used for deep analysis at a later time
Thread Level Socket Read/Write details
GC Pause – Young and Tenured map
Detailed Thread analysis

Garbage Collection log analysis

Problem: Often it is not possible to run a profiler at runtime because
1. Running on the same host uses up resources
2. Running on a remote resource produces JMX connectivity issues due to firewall etc
Solution:
1. Enable GC Logging using the following JVM command line arguments
  -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintTenuringDistribution -Xloggc:%GC_LOG_HOME%/logs/gc.log
2. Ensure the GC_LOG_HOME is not on a Remote host (i.e. no overhead in writing GC logs
3. Analyse logs using a tool
  1. Example: GC Viewer https://github.com/chewiebug/GCViewer

Using the GC Viewer Tool to analyse GC Logs
1. Download the tool
  1. https://github.com/chewiebug/GCViewer
2. Import a GC log file
3. View Summary
  1. Gives a summary of the Garbage Collection
  2. Total number of concurrent collections, minor and major collections
  3. Usage Scenario:
    ” Your application runs fine but occasionally you are seeing issues with slowed performance … it could be possible that there is a Serial Garbage Collector running which stops all processing (threads) and cleans memory. Use the summary view GC Viewer to look for Long pauses in the Full GC Pause”
4. View Detailed Heap Info
  1. Gives a view of the growing heap sizes in Young and Old generation over time (horizontal axis)
  2. Moving the slide bar moves time along and the “zig-zag” patters rise and fall with rising memory usage and clearing
  3. Vertical lines show instances when “collections” of the “garbage” take place
    1. Too many close lines indicate frequent collection (and interruption to the application if collections are not parallel) – bad, this means frequent minor collections
    2. Tall and Thick lines indicate longer collection (usually Full GC) – bad, this means longer full GC pauses