JVM Heap Size in VMware Visitors

This question is probably better worded: how does the operation of a Java server on a hypervisor such as VMware ESX affect a bunch of Java?

  • JVM heap access is random from OS / hypervisor perspective
  • It is difficult for a guest OS or hypervisor to optimize RAM
  • Given this, can the hypervisor detect unused pages in the JVM heap?

Common to Java server applications is that performance is better if you allocate the entire heap when starting the JVM, rather than letting the heap dynamically resize as needed. In other words, if you set the heap size to 1 GB, your Java process will get 1 GB of contiguous virtual address space (+ everything you need for binary files), memory that is no longer available to other applications.

Is VMware smart enough to detect that part of this heap is not actually used? How does this affect GC performance? Would it be better to let heap sizes dynamically change in VMware? What GC strategies work best with VMware guests?

Also, will someone tell me some guidelines for setting up JVM heaps in virtualized environments?

+6
java memory vmware
source share
2 answers

Regarding my question:

Here is a PDF that provides a broad overview of Java usage considerations for VMware guests: link text

+5
source share

so in this case make sure Reservation = OS vRAM + JVM + heap size hope this helps.

but meanwhile, the following are general recommendations of the VMware KB site:

The size of the virtual machine memory to leave enough space for the Java heap, other memory requirements for the code and stack of the Java virtual machine, and any other simultaneous execution process that requires memory from the guest operating system.

Set the memory reservation value in the VMware infrastructure client to the memory size for the virtual machine. Because any type of memory replacement (physical or virtual) is detrimental to JVM heap performance, especially to garbage collection.

Determine the optimal number of virtual processors for the virtual machine hosting the Java application by testing a virtual machine configured with a different number of virtual processors at different times with the same load.

If you use multiple Collector Garbage threads in your JVM, compare the number of these threads with the number of virtual processors configured on the virtual machine.

To simplify monitoring and load balancing, use one JVM process for each virtual machine.

If your ESX server is overloaded, make sure that the virtual ball driver is running on the virtual machine to optimally manage memory.

+2
source share

All Articles