VMware vSphere

I sat in on an enlightening session (TA2627 Understanding Host and Guest Memory and other memory management ...) and took the information from that session to reviewed my current cluster statistics finding that guest usage is consistently much lower than Host usage stats. My HOST do not have any sign of initiating Ballooning or swapping however the Host memory usage is nearing 70 % total capacity on each host.

We are trying to devise some metrics surrounding cluster resources that will trigger alerts for adding capacity to the cluster as needed however would like to balance the alerts allowing us to commit resources based on actual usage rates. As it stands now our Host memory usage will be pushed beyond current default warning thresholds from a virtual center alerts stand point but actual guest usage rates will be far from exceeding total memory commitments currently allocated. We would like to understand some key metrics to monitor to avoid performance issues while allowing to oversubscribe resources based on actual VM usage. We sell resources for servers incrementally and are finding that in many cases customers are purchasing more resources that they really require to run their services.

Any ideas or key metrics to monitor that will enable us to setup alerting for capacity upgrades?

Should we consider capacity upgrades when ESX Host reach 90% usage even while guest VM usage combined in no where near that total percentage of memory being used??

Thanks

Hi Wade,

I realize that no-one has responded to this query, and thought I'd pipe in (albeit late). We are using a product called Capacity Analyzer sold by VKernel (http://www.vkernel.com). The one thing that I noted is that it uses Memory Consumed, as opposed to Memory Active to rate resource utilizations at the VM & host levels. The host levels in fact, only reflect the percentage of usage based on the total guest VM usage and how it relates to the host itself. Using these (host graphs) against the VIC graphs we were able to also see whether any memory issues were heap related or tied to some other host level memory issues.

Using Memory Consumed (and you will find arguments all over this community) was good for us from the constraint perspective. It represents all the memory being tied up by the VMs, and is usually not limited to only showing what memory pages are active.

For us though, it was mostly CPU & CPU Ready that was our chief constraints. We had over-allocated vCPU to our VMs, and they were causing processor contentions within the host. I'd say check out the vkernel tools () especially the Capacity Analyzer as well as the Optimization Pack.

Thanks. That is helpful and i will take a look at the tool.

Check this out too. It may be useful since there is a lot of topic surrounding over-allocation.

• Allocating more memory than needed unnecessarily increases the virtual machine memory overhead, thus using up memory that could be used to support more virtual machines.When possible, configure 32-bit

• Linux virtual machines with no more than 896MB of memory. 32-bit Linux kernels use different techniques to map memory on systems with more than 896MB. These techniques impose additional overhead on the virtual machine monitor and can result in slightly reduced performance.

• ESX allows significant memory overcommitment, usually with little or no impact on performance. You should avoid overcommitting memory to the point that it results in heavy memory reclamation (i.e. ballooning and swapping).

• VMware Tools also includes the balloon driver used for memory reclamation in ESX. Ballooning will not work if VMware Tools is not installed

However, if a given VM spikes demand for memory, beyond expectation, so the balloon process is pinched, or worse VMs are allocated memory beyond physical memory and physical memory is exceeded by demand requests, ESX host will page to disk via the swap configuration, and then every single VM, regardless of or if they requested memory will be impacted because writting to swap is painful to performance. WIth memory so inexpensive and many if not all servers running lots of RAM for virtualization, any overcommitment of memory should be avoided. Best practice is to not over subscribe memory unless you really know when and how applications in VM memory demand trends proceed. Memory overcommitment can lead to network or disk IO overcommitment beyond typical peak scaling. I have seen ESX hosts chase their respective tails trying to perform when memory oversubscription leads to network and/or disk IO additional over subscription... all because some PM or purchasing resource did not want to spend on relatively inexpensive RAM? The first thing I encourse clients to do... is increase RAM when an ESX host is struggling with this issue. You would be surprised with the results!