2

We are currently having a discussion in my environment. The assumptions are that

“The tools that are designed for a physical infrastructure memory management in Linux such as top, free, vmstat, /proc/meminfo don’t work on a VM in an ESXi hypervisor because they rely on the OS’s ability to monitor the physical RAM directly in a bare metal system. In a virtual infrastructure, the guest OS can't see the physical hardware, only the virtual hardware that has been emulated by the (ESXi) hypervisor. Because an OS can't directly access most of the host server's physical hardware, traditional performance monitoring tools won't function properly in a virtual infrastructure.”

In the VM guest (SLES 11) we’re seeing RAM utilization at around 93%. However in the vSphere/vCops is showing 5072309 kb Active Write of 8388608 (8GB) KB of allocated RAM. Roughly about 60.46 % utilization rate.

The question, is the above assumption correct and if so:

If top inside the guest is inaccurate in the VM and it reaches 100% RAM utilization does the VM guest then swap and if so I presume with the vswp which is located on the SAN and cause a slowdown on the VM Guest?

ewwhite
  • 194,921
  • 91
  • 434
  • 799
Phil
  • 31
  • 2
  • What is "even though Active is not"? I think it is like a downvote? – peterh Aug 01 '14 at 15:13
  • The metric in vCops is "Memory | Active Write (KB)". Amount of memory that is actively used, as estimated by VMkernel based on recently touched memory pages. Virtual machine: Amount of guest “physical” memory actively used. Per https://www.vmware.com/support/developer/vc-sdk/visdk400pubs/ReferenceGuide/memory_counters.html – Phil Aug 01 '14 at 15:17
  • I suggest to reformulate your question, it is very far not understable. – peterh Aug 01 '14 at 15:22

1 Answers1

1

It depends. You should rely on the in-VM tools like top, vmstat, etc. They are accurate, assuming that your physical resources aren't too overcommitted and you've installed the VMware tools. At the vSphere level, you still have memory ballooning, TPS, compression and swap as fallbacks. The memory management really isn't that bad.

Also understand that vSphere/vCenter metrics and vCops metrics are totally different (vCops was acquired by VMware and uses its own algorithms to measure resource utilization).

Measure utilization at the VM level. Plan cluster-level resources using vCops or vCenter.

Don't overcommit your RAM too much because that WILL skew metrics and have a tangible performance impact.

They type of application also matters. If it's heavy Java-based, some other approaches (partial or full reservations) are necessary to help them run effectively in a vSphere environment.

Community
  • 1
ewwhite
  • 194,921
  • 91
  • 434
  • 799
  • Wow, I didn’t know that vCops ran a different algorithm, I thought that it pulled it’s metrics from ESXTOP. We definitely have the tools installed so are you talking about the ESXi host ballooning or the VM guest? I thought ballooning was just something the host did so it doesn’t swap. We didn’t set the VM guests to overcommit memory at first. We do have DRS turned on so I hope it’s balancing it out. I just check and we’re not overcommitted on the host that holds the vm in question 37 committed to 72 GB available physical RAM. – Phil Aug 01 '14 at 15:37
  • You can overcommit, but not TOO much. My extreme example had a 4:1 overcommit on RAM, so the VMs were stealing from each other. – ewwhite Aug 01 '14 at 15:40