Analyzing Efficiency Of Java Memory Usage

Ruslan Synytsky rs at
Wed Jul 15 19:06:47 UTC 2020

Hi all, I would like to share some preliminary results related to Java
elasticity analysis. We collected metrics from about 1000 containers. The
goal was to get a rough picture of the memory usage efficiency within our
user base.These containers are running different software stacks, java
versions, dev or production workloads, and they belong to different end
users. Each container may have one or multiple Java processes running
inside and even additional auxiliary non Java processes.

At the following link you can find a dynamic chart that reflects memory
usage at specific period of time (it's one time measurement)
- X axis represent Hosts, each host is a separated container
- Y Axis:
  * OSTotal: total RAM available for container
  * Xmx: max heap limit
  * NonHeapCommitted+: committed non heap stacked on top of committed heap
  * HeapCommitted: committed heap memory
  * HeapUsed: used heap memory
  * OSBuffCache+: OS memory in buffer / cache stacked on top of OS used
  * OSUsed: OS used memory
  * Count: number of java processes running inside the host
  * Java Version per each Java process
  * GC type per each Java process
  * Java Agent: n/count - how many processes are using jelastic GC agent
 (was used before JEP 346)
  * G1PeriodicGCInterval: n/count - how many processes are using this new

The chart is ordered from left to right by the following sequence
OSTotal, Xmx, NonHeapCommitted, HeapCommitted,
HeapUsed, OSBuffCache, OSUsed.

In general, the results look good as the vast majority of java processes
are running in a quite efficient mode (small difference between used heap
and committed heap). There are some java processes that have a big
difference between used heap and committed heap (for example host 91 or
host 109), but such processes do not use memory usage optimization (no
configured GC agent and no G1PeriodicGCInterval) or they use non-compacting
GC. Interesting findings that a) sometimes committed heap memory is
higher than real OS used memory, and b) in many cases non heap committed
memory is as big as heap committed.

Please note, the analysis does not represent all possible use cases and
rather represent web applications and services that are hosted at local
cloud hosting providers. Also, most likely our analysis does not reflect
the reality outside of Jelastic, because by default we optimize Java
runtimes for the maximum efficiency in terms of memory usage, so I expect
that the real world situation is worse.

We are planning to add more containers to the analysis for getting an even
bigger picture, but also I'm looking for other companies that can join this
analysis. It will help the community to get a better understanding of the
real (diverse and heterogeneous) Java world. Please let me know if you are
willing to participate and I will share a bash script that collects the
memory usage metrics (it will not collect sensitive or personal information
as well as it's safe to run on productions).

Looking forward to getting your feedback.
Ruslan Synytsky
CEO @ Jelastic Multi-Cloud PaaS

More information about the hotspot-gc-dev mailing list