Elastic Memory for Java (EM4J) 1.1 is a memory management toolkit for Java in vSphere, focused on enabling customers to confidently achieve greater memory efficiency for their Java workloads.
EM4J is a relatively new technology developed here at VMware which was created to solve the problem of memory reclamation in VMs predominantly running Java. This week, as part of the overall vFabric Suite 5.1 release, we introduced EM4J 1.1 which builds on that foundation with new monitoring capabilities in vCenter designed specifically to support Java workloads, as shown in this screenshot. First, however, if you are not familiar with EM4J, it may be helpful for a more detailed background on EM4J itself. If you are already familiar with it, you can skip to the section below on EM4J 1.1.
Using EM4J to Monitor JVM Heap Memory
What does EM4J do?
Traditionally, you can configure VMs to run in less memory on the host than is available in the guest by enabling features such as guest ballooning. Guest ballooning allows the hypervisor to borrow memory from a less active VM and lend it to a more active one, with the aim of meeting a pre-configured memory resource constraint on the host. However, applying memory pressure with a balloon to the guest OS can be ineffective for a runtime such as Java, which manages all of its memory in its own closed world that the guest has no access to. EM4J instead targets that balloon pressure directly where it should be: at the JVM itself.
So, what did this mean for Java workloads in practice? Until we released EM4J, we advised against over-committing memory with Java. This is not to say that it was impossible to make it work, but the provisos were overly complex and the consequences of getting it wrong were too expensive.
With EM4J you now have the ability and the confidence to drive up hardware utilization for Java workloads. In most Java environments, memory is the limiting factor, not CPU. If only memory could be used more efficiently, you could get better hardware utilization and more bang for the buck.
So, how is this “elastic”? It’s simple. EM4J levels the playing field for Java. Whatever elastic resource management advantages virtualization gave you with non-Java workloads are now available to Java too. In practice, constraining (over-committing) memory for VMs causes the hypervisor to have to juggle resources – it takes memory from less active VMs and makes it available to more active ones.
Let’s consider an example. Imagine you have Java workloads that serve different geographies in separate groups of VMs. When Asia is most active, the US is asleep. At the end of each active period in Asia, the Asia JVM heaps are full of stale session data, cache data etc. For the next 12 hours, those VMs will be relatively idle and the memory being consumed to store all that garbage and cold cache data is wasted. You could be putting that memory to much better use in your US VMs! With EM4J, the hypervisor can balloon into the JVM heaps of the Asia servers and reclaim that memory so that it can be used by the US ones. Once the US winds down, the Asia JVMs can just kick the balloon out of their heaps to take memory back from the US servers.
EM4J 1.1: Enhanced vCenter monitoring, Java 7, Red Hat, and Apache Tomcat
EM4J 1.1 Highlights:
- Enhanced vCenter monitoring for all Java workloads
- Java Best Practice Analyzer and memory tuning advice
- Dynamic insight into appropriately sizing VMs for Java
- First class support for EM4J ballooning in vCenter monitoring
- Java 7 support
- RedHat Enterprise Linux 6 support
- Apache Tomcat 6 and 7 support
In talking to customers and working with our own QA and performance teams, we realized that we needed to give vSphere administrators better insight into Java VMs to empower them to make better resource allocation decisions. Sizing VMs appropriately, for example, is an important first step towards making more efficient use of memory. Maybe you suspect that the large VMs you’re handing out are being seriously under-utilized—how can you really know?
Well, we already have products, such as vFabric Hyperic that can give you insight into the performance of the JVM. We have vCenter which can give you insight into the performance of your ESXi VMs and hosts. However, in order to make informed configuration decisions of a large dynamic system, you need key information from all the layers of the stack and a simple tool to interpret that information and make it easy to consume.
So in EM4J 1.1, we have a vCenter plugin and a lightweight monitoring agent which gives you exactly that. It takes much of the static advice and calculations from our best practice and tuning guides and makes it available to you in real time.
In addition we have made it easier for customers to see a before and after picture of EM4J’s Java ballooning by providing first class support directly in the monitoring tool that clearly shows memory being ballooned from the JVM heap, rather than the guest OS.
A comprehensive blog and video to illustrate you this capability will be coming very soon. In the meantime, here’s a summary of a few of the other key features:
Enhanced vCenter monitoring for all Java workloads
The monitoring described above does not require EM4J ballooning, but can monitor any Java workload running on the Hotspot JVM. For many customers, having more insight into the memory needs of their Java workloads will not only lead to more confident management, but can then be a stepping stone to using EM4J ballooning.
Java Best Practice Analyzer and memory tuning advice
We took some of the most useful advice from our best practice guides and baked it directly into a series of alerts that operate at both the VM and the JVM workload granularity. These alerts not only pick up on common misconfigurations that can lead to performance problems, they also give you advise on how to remedy it.
Dynamic insight into appropriately sizing VMs for Java
Our monitoring solution will show you up to a week’s worth of Java memory usage, break it down into useful categories and effectively illustrate how efficiently you areusing the memory in your VM. For example, if the JVM is leaking memory, causing guest paging, this will show up very clearly. Additionally, you can also drill down into each Java process from vCenter and see everything from GC statistics to PID to heap usage.
Java 7 support
EM4J has now been tested and tuned to support Hotspot JDK 7.
RedHat Enterprise Linux 6 support
EM4J has now been tested and validated with Redhat Enterprise Linux 6.
Apache Tomcat 6 and 7 support
The EM4J ballooning agent plugs into the Hotspot JVM and is shipped in vFabric as part of tc Server. We now support EM4J in the regular open-source Apache Tomcat and already have a knowledge base article on how to configure this.