It does not make a difference. You have reasoned correctly.

Scott

Thanks for your response.

According to the vSphere Resource Management Guide (vsp_41_resource_mgmt.pdf) page 107, the maximum amount of memory reclaimed by the balloon driver is 65% of the total memory allocated to a VM.

If I have a 4 GB VM, and I calculate OS, JVM + Heap = 1GB, which is 25% of total allocated, I know the balloon driver won’t hit at least 35% of my memory.

Therefore, in situations where OS, JVM + Heap is less than 35% of total allocated VM memory, does it actually make any difference setting a reservation on that VM?

Regards
mark

The guest will avoid swapping memory that is in use. The Java memory space is generally being used in its entirety because garbage collection will be sweeping the entire heap regularly. So, setting reservations to account for everything actively in use (including the entire heap) protect enough memory for the guest processes to run without being paged out by the guest OS.

With respect to comment [2], this is not an exact science. But we can reasonably trust any guest’s memory management will page out less active processes over more active ones. But it is true that if the active memory spiked above the un-ballooned memory then the guest will have to swap. It is just as likely to swap Java memory as anything else so at this point performance will probably suffer.

Scott

Thanks for your response.

I’m still not clear on the mechanics of why setting a memory reservation for Java workloads is beneficial?

I am thinking the following concepts:

[1]
Because there is a memory reservation, there is less memory available for the balloon driver to inflate into, thus reducing the possibility of swapping to disk key areas of JRE memory.

[2]
If the Guest OS can’t “see” inside the JRE memory, how is it actually going to “do the right thing” and swap out the most active processes? Are we in fact just rolling the dice here and hoping the Guest OS won’t swap out key JRE memory or is there more science than that?

Would really appreciate it if you could break this down to the next level of detail, as I’m still confused.

Regards,
mark

[1] Anything that runs an interpreter/simulator like Java in the guest OS could cause the same problem. I am defining interpreter/simulator here as something that manages its threads’ memory inside the process. I am aware of no other applications except Java that behave this way, although I would expect the same out of .NET.

[2] You cannot tell what ends up in the reserved memory. But it does not matter where the memory is until the ballon driver starts to inflate. At that time it will start to take memory from the guest OS, forcing it to page out low-priority processes. Usually it will do the right thing and choose the most active process(es).

Scott

You posted this message a while ago over on vmware:

http://communities.vmware.com/blogs/drummonds/2009/09/09/love-your-balloon-driver

Couple of questions

[1]

You mentioned because Java has its own memory management it is wise to set a reservation for Java.

Are there ANY OTHER enteprise applications/situations where the VM’s OS can not “see” what is going on inside its own memory, as in the case with Java? Or is it just Java that causes this issue?

[2]

For Java, you mention it is wise to set a reservation to account for the JVM,OS, and heap. Say I have a 4GB VM, and I calculate JVM+OS+Heap = 1GB, and I set a reservation for 1GB.

Because the JVM/OS/Heap will load first, does that mean that those components will end up “landing” inside that 1GB i’ve reserved? And thus, if balloon driver DOES inflate, at least it won’t swap out fundamental JVM/heap components? Is this reason for recommending to set the mem. reservation for java?

Or another way of putting it, what ends up sitting in that 1GB that i’ve reserved?.. and can this change during the lifetime of a VM? How do I ensure that the JVM/OS is what ends up in the 1GB i’ve reserved, as is the intention?

Regards
mark

Scott