What is VM Ready Queue & How Do You Manage it? | Turbonomic
You want to get the best possible performance for your applications, and logic might lead you to believe that more CPUs allocated to a VM would only improve performance, but the issue of Ready Queue defies that logic.
In this video you will learn why VM ready queue tends to defy logic and how you can manage it regardless of it’s many trappings.
The Ready Queue Conundrum: https://turbonomic.com/blog/on-technology/ops-mars-devs-venus-pt-2-ready-ready-queue-sizing-conundrum/
Why Over Provisioning Will Not Guarantee Perfomance: https://turbonomic.com/blog/on-turbonomic/why-over-provisioning-will-not-guarantee-performance/
Ready Queue Causes & Mitigation: https://turbonomic.com/blog/on-technology/ops-mars-devs-venus-ready-queue-pt-2/
About Turbonomic: https://turbonomic.com/
You know those frustrating application issues that pop-up and then disappear before you can trace root cause like a whack-a-mole game? The cause may not be your code, but rather VMs being too big.
You want to get the best possible performance for your apps, and logic might lead one to believe that more CPUs allocated to a VM would only improve performance, but the issue of Ready Queue defies that logic. Let’s see how.
A physical host with 16 cores that has been virtualized may share its physical resources with multiple virtual machines – sometimes 10 or more. This shared use of resources is one of the most powerful aspects of virtualization. But when a VM is over-sized, with say a 16 vCPU allocation, it takes up all resources on the host whether or not it actually needs those resources.
All other VMs, whether sized from 1 vCPU to 16 vCPU or anywhere in between, must then wait for that VM to complete its scheduled processes before they can begin their scheduled processes; creating latency in accessing compute cycles for all end-users tied to those VMs in the queue. In effect, the big VM at the table is hogging all the resources, likely far greater than it can use, causing the others to starve until its processing is done.
A similar issue can arise when VMs are provisioned with over-allocated memory resources.However, if we re-size the VM to, say, 2 vCPU rather than 16, we see how physical resources are more efficiently allocated, reducing wait times for each VM to begin processing, increasing performance for all VMs and improving the end-user experience.
The other benefit of avoiding over-sizing is that each blade now has more room, meaning each VM has more options if it needs to move to avoid a noisy or busy neighbor. More options means better performance for every workload, including your own.
Given these issues, a best practice in a virtualized environment is to size a VM minimally, both on provisioning and after workload initialization, then add resources as end-user demand dictates. In virtualized environments, both virtual CPU and Memory resources can be added without needing to re-start the VM (a process known as “hot add”).
Cutting edge IT operations are making use of standardized VM deployment models with smaller initial VM sizing, and instead of manually configuring VMs one at a time, advanced automation is used to resize resources up to meet application workload demand in real time. This VM right sizing will actually improve application performance, while managing resources more effectively, and will also aim to optimize current workloads.
Turbonomic looks at all resources holistically, in real time, and understands the tradeoffs between not only CPU and Memory, but also network, storage, and indeed all aspects of the data center supply chain. Turbonomic then correlates those tradeoffs with application demand at that very moment. This enables every workload to get exactly the resources it needs in real time – no more, but importantly no less – to assure application performance for the end user.
By sizing VMs conservatively we can avoid CPU and Memory resource contention leading to latency and other performance degradation impacting end users, while hot adding resources to specific VMs like the one here when application demand increases. Current VMs in the infrastructure will be included in the auto upsizing program, combined with a downsizing program to get running VMs optimized, and increase utilization of datacenter hardware.
In this way, your environment will remain in a goldilocks state where no VM has too many – or too few – resources, and healthy application performance is assured, no matter how popular your apps become.