Database Reference
In-Depth Information
not within its own NUMA node, the data must be transferred over from the other node.
This is slower than accessing memory within the NUMA node itself. Memory access
times are non-uniform and depend on the location of the memory and the particular node
it is coming from—thus the term “non-uniform memory access.”
If the system illustrated in
Figure 7.11
has a total of 128GB of RAM associated with it,
then each NUMA node would consist of 32GB of RAM. For optimal performance, the
total size of each virtual machine should be less than 32GB. This would ensure optimal
performance because you would never have to take the performance hit associated with
spanning NUMA nodes. If you don't know the NUMA node size, ask your server
vendor.
Just as a database page has a certain percentage of each page reserved for page
management, the same holds true for vSphere memory management. Within that 32GB
NUMA node, a very small percentage of the 32GB will be utilized by the hypervisor for
memory management. You should always size your VM's knowing a little off the top is
reserved for memory management, so in this example, the maximum size a VM can be to
fit within the NUMA node is slightly less that the 32GB. An excellent blog article from
VMware that talks about this overhead can be found at
It's worth noting here that the remote access penalty is the same for a physical
implementation as it is for virtual implementations.
Tip
To avoid NUMA remote memory access, size your virtual machine memory to
less than the memory per NUMA node. Don't forget to leave a little room for
memory management overhead.
VMware is NUMA aware. When a virtual machine first powers on, it is assigned a
home NUMA node. Think of a NUMA node as a set of processors and memory. It will
keep a particular VM running on the same NUMA node. If the hypervisor detects that the
NUMA node the VM is running on is busy, it will migrate the VM to another NUMA
node to get better performance. It is important to note that when you hot-plug a CPU, you
affect vSphere's ability to utilize NUMA. The two capabilities do not work well
together. When vSphere first starts up, it establishes the NUMA home nodes based on
the number of CPUs. When a CPU is hot-plugged, it affects these settings. In effect, it
disables vSphere's ability to use NUMA. Our experience has taught us that NUMA is
much more beneficial to the performance of your SQL Server database than the ability
to hot-plug a CPU.
vNUMA
