# The Ultimate Guide to Right-Sizing CPU & Memory for Virtual Machines

In the world of virtualization, more CPU and memory doesn’t always mean better performance. Over-provisioning resources can lead to higher contention and even degraded application responsiveness.

Right-sizing ensures your workloads get exactly the resources they need—no more, no less—while maximizing efficiency on your ESXi hosts.

In this guide, we’ll explore **practical CPU and memory sizing strategies**, **NUMA awareness**, and **performance optimization tips** to help you make data-driven decisions.

## **Why Right-Sizing Matters**

Every ESXi host has finite CPU and memory resources. If one VM hoards them unnecessarily, other VMs suffer. The goal of right-sizing is to:

* Improve **overall cluster performance** by [reducing contention.](https://automatestack.dev/resource-contention-in-vsphere-identification-and-solutions)
    
* Optimize **hardware utilization**.
    
* Avoid **VM-level performance degradation** caused by unnecessary over-allocation.
    
* Reduce **software licensing costs** for CPU-bound products like databases.
    

## **CPU Right-Sizing**

When it comes to CPU allocation, more isn’t always better. Virtual CPUs (vCPUs) introduce scheduling overhead—allocating more than necessary can slow things down.

### **Best Practices**

1. **Start Small**
    
    * Begin with the minimum number of vCPUs required for peak load.
        
    * Common starting point: **2 vCPUs** for general-purpose workloads.
        
2. **Add CPUs Only When Needed**
    
    * Monitor for **CPU Ready Time** or **Co-stop** events.
        
    * If they are consistently high, then consider adding more vCPUs.
        
3. **Align with NUMA Topology**
    
    * Configure vCPUs as **Cores per Socket** until:
        
        * You exceed the physical core count of a NUMA node, or
            
        * You exceed the memory available in a NUMA node.
            
4. **Avoid Odd vCPU Counts**
    
    * Maintain even counts for better scheduling efficiency.
        
5. **Disable vCPU Hot Add Unless Necessary**
    
    * Enabling hot add disables **vNUMA**—critical for workloads over 8 vCPUs.
        
6. **Mind Licensing Models**
    
    * **some software licensing schemes had limitations on socket counts**, configuring the socket count to 1 may result in better performance
        
        * For example, SQL Server Standard edition running on an 8-vCPU VM with 1 core per socket would be able to utilize only 4 vCPUs. But if the same VM were configured with 1 socket (that is, 8 cores per socket), then all 8 vCPUs would be leveraged.
            

## **Understanding NUMA & vNUMA**

Modern servers use **NUMA (Non-Uniform Memory Access)**, where CPU and memory are grouped into **nodes**. Accessing memory within the same node is faster (local memory) than accessing from another (remote memory).

* Let’s understand with an example. Lets assume:
    
    * Each physical server has **2 CPU sockets**.
        
    * Each socket contains **24 physical cores**.
        
    * This means **one NUMA node = 1 socket = 24 cores + its own memory bank**.
        
    
    If you create a VM with **up to 24 vCPUs**, you can assign them as **1 socket × 24 cores**.
    
    * This keeps **all vCPUs within the same NUMA node**, so memory access stays local and fast.
        
    
    If you create a VM with **more than 24 vCPUs** (say 32 vCPUs):
    
    * The vCPUs will be split across **two NUMA nodes** (because a single node can’t handle more than 24).
        
    * This means some CPU threads may need to access memory from the other node, which is **slower**.
        
    * At that point, you should configure vNUMA so the VM and its OS are aware of this split.
        

### **NUMA Tips**

* Keep vCPUs and memory allocations **within a single NUMA node** when possible.
    
* **vNUMA** becomes relevant when a VM’s vCPUs exceed a single NUMA node’s core count (often >8 vCPUs).
    
* vNUMA exposes NUMA topology to the guest OS so it can optimize memory locality.
    

## **Memory Right-Sizing**

Just like CPU, over-allocating RAM can harm performance due to ballooning and swapping.

### **Best Practices**

1. **Start with the Working Set**
    
    * Measure actual memory use and allocate slightly above it.
        
    * Example: If a VM uses 8 GB, allocate ~10 GB.
        
2. **Avoid Large Headroom**
    
    * Unused RAM may be reclaimed by ballooning, which can cause performance drops.
        
3. **When Ballooning Occurs**
    
    * Check if the VM is swapping/paging.
        
    * Right-size VMs with over-allocated RAM to free resources for others.
        

## **Final Thoughts**

Right-sizing isn’t about giving VMs the **most** resources—it’s about giving them the **right** amount. By starting small, monitoring real usage, and scaling based on evidence, it will lead to boosting performance & [reduce resource contention](https://automatestack.dev/resource-contention-in-vsphere-identification-and-solutions).

Awareness of physical topology and NUMA limits is also key to making the most of your hardware.