Revised December 6, 2012.
This section describes the EM4J supported configurations and system requirements.
The following table lists supported platforms for this release of EM4J.
Table 1. EM4J 1.2 Agent Platform Support
|Red Hat Enterprise Linux||v5||x86_32||Java SE 6|
|Red Hat Enterprise Linux||v5||x86_64||Java SE 6|
|Red Hat Enterprise Linux||v5||x86_64||Java SE 7|
|Red Hat Enterprise Linux||v6||x86_64||Java SE 6|
|Red Hat Enterprise Linux||v6||x86_64||Java SE 7|
EM4J is compatible with VMware ESXi 5.0 or greater. Virtual machines must be hardware level 7 or greater. A VM at hardware level 7 that is running EM4J can be migrated to ESXi 4.1 and back to ESXi 5.0, but EM4J ballooning is only supported when the VM is on an ESXi 5.0 or greater host.
The EM4J 1.2 agent is supported with the following Java workloads using a supported JVM:
vFabric tc Server 2.8
Apache Tomcat 6.0
Apache Tomcat 7.0
The EM4J Plug-in for vSphere Web Client may be installed in vSphere Web Client 5.0 or vSphere Web Client 5.1, running on Windows Server or on the vSphere vCenter Appliance.
The plug-in may be downloaded from the VMware Downloads Web site for VMware vFabric. There are specific versions of the plug-in for vSphere 5.0 and vSphere 5.1.
When you enable EM4J in a virtual machine, memory outside of the Java heap is not reclaimed with ballooning technology (although it may be reclaimed by other ESXi strategies). For this reason, EM4J should only be used in configurations where the majority of memory is used by a Java heap.
EM4J ballooning technology works with ESXi 5.0 or greater.
EM4J does not function in heap sizes smaller than 512MB.
EM4J currently can reclaim a maximum of 4GB from a Java heap.
EM4J works equally well in virtual machines with large pages enabled as with small pages.
You can run more than one EM4J-enabled tc Runtime instance in a virtual machine. Each instance contributes to the overall balloon for the virtual machine. However, the individual instances do not coordinate ballooning with each other, so running large numbers of instances is not currently recommended. A pragmatic limit is four EM4J-enabled tc Runtime instances.
Over-committing memory always has some cost, regardless of which ESXi memory sharing strategies are employed. Some applications may be so highly performance-sensitive that over-committing memory is unsuitable for them. EM4J can increase the frequency of garbage collections, but does not increase the pause times for full garbage collections. There can be a small effect on response times and latencies, which may be unacceptable for some applications.