Back to Blog

Ben Yemini

vMem, To Size or Not To Size?

Virtual Memory (vMem) has made life a bit easier for applications. With a typical deployment of one application and one OS per virtual machine, applications no longer have to manage a shared memory space with other applications. It has also increased security by making it easy to isolate unstable or compromised applications, and provide fast disaster recovery solutions. And apps are now able to conceptually use more memory than might be physically available.

But this same technology has also introduced workload interference and demand peaks, which make correct workload distribution and sizing extremely difficult and impossible to perform in real time.

When it comes to virtual memory management a typical conversation with a potential VMTurbo user may start along the lines of:

Ops team member: 

"We recently consolidated two data centers with IBM servers and Hitachi Storage on to Cisco UCS blades and EMC VNX storage. With the added compute and storage capacity and performance, we’re virtualizing everything we can."

"We’ve been able to add users at a much more rapid pace, but I still get nervous… what if somebody in California can’t access their SQL instance?  What if SQL continues to consume all of the memory and queries start to get very slow?"

So how does our Operations Manager overcome the SQL memory performance issues and prevent them from occurring in the first place?

VMTurbo’s Operations Manager abstracts each of the aspects of your environment including application workloads, compute, storage and network resources into a common data model. It applies an economic model to IT management and your datacenter. As an example, application workloads and VMs drive the demand while hosts and datastores supply them. This patterned approach assures application workload performance while utilizing the underlying infrastructure as efficiently as possible.

Let’s look a little bit closer at the SQL example. Its VM template has been configured with 4 vCPUs and 8 GB of vMem. As users execute queries, SQL is continuously caching memory to improve performance. The SQL VM starts to consume more of the memory it has been allocated, and could potentially cause users to experience latency or even fail.

SQL Workload

In VMTurbo’s supply chain, the application is purchasing vMem from the VM, and the VM is purchasing memory from the host. As SQL consumes more of the VM vMem, VMTurbo is aware.


In the example below, the SQL VM has been allocated 8 GB of memory capacity, on average it has been using 10 GB of memory and utilization of 122%.


VMTurbo is also aware of the host memory supply. In this case the capacity of 100 GB. The host is using 76 GB with a utilization of 76%.

host ui

It is also aware of other key resources. For example, one of the datastores below with 6 TB of capacity is 8.8% utilized.

datastore UI

The price of memory on the host is based on an inverse relationship to utilization. As the utilization increases and memory becomes more scarce, the price increases asymptotically, i.e. price rises much more rapidly as utilization approaches 100% and can eventually reach infinity.

price curve

In this case, there is still plenty of capacity on the current host to satisfy the vMem demand of the VM which will be consumed by SQL. VMTurbo’s recommendation is therefore to increase the vMem capacity by 5 GB, from 8 to 13 GB.

increase vMem action

Now let’s look at another example. In this case the VM is running on a host (vmturbocloud5) that has been running at 84% utilization. There is another host (vmturbocloud1) on the same cluster running at 68%.

hosts on cluster

Rather than increase vMem capacity on the VM and therefore raise the price for all VMs running on this host, VMTurbo recommends a move to the host with less expensive memory (vmturbocloud1) and will then recommend to increase the vMem capacity.

vMove action

Leveraging efficient market principles, VMTurbo resolves and prevents performance issues from occurring, while maximizing the utilization of underlying physical IT assets.

We just considered one workload and two potential scenario. If you have 100 VMs, 10 hosts and 15 datastores, the number of potential sizing and placement decisions quickly reaches the 1000s, not something a sysadmin or even a team of sysadmins can figure out in real-time.

So don’t waste your time figuring out the right vMem size, give VMTurbo a try and see how it can help performance issues disappear.

Triangle: Performance

This article is about performance. Read more like it at the Performance, Efficiency, Agility series.