I’ve blogged about NUMA a couple of times in the past and we cover it extensively in our Immersion Events, specifically when discussing SQLOS and memory and scheduling management. One of the challenges with this is that laptops are SMP machines, so unless you have a server with hardware NUMA it is impossible to show the differences in how SQLOS boots up with or without NUMA, at least that’s what I used to think. It turns out that in Windows 7 and Windows Server 2008 R2, the support for > 64 processor support and processor groups allows you to be able to fake a hardware NUMA configuration at the OS level for testing purposes.
To show how this works I am going to use one of my test VMs running in VMware Workstation 8 on my Dell M6700 laptop that I use regularly for teaching and presentation demos. For the purposes of this post I have reconfigured the VM to have four CPUs with two cores each and 16GB RAM.
SMP Configuration (Default)
Under the default configuration of the VM has a single memory node presented by Windows to SQLOS so it starts up with a single NUMA node and all of the logical processors are assigned to that node, as shown in the Server Properties dialog below.
We can also see this information from the DMVs with the following query:
, n.node_id AS cpu_node_id
FROM sys.dm_os_memory_nodes AS mn
INNER JOIN sys.dm_os_nodes AS n
ON mn.memory_node_id = n.memory_node_id;
NUMA Configuration (bcdedit)
A fake NUMA configuration can be created by setting the groupsize value in the Boot Configuration Data (BCD) using BCDEdit to the number of CPUs that should be grouped into each processor group. The appropriate values are 1 to 64 in powers of 2. This isn’t documented in the standard BCDEdit documentation in the Books Online, but it is documented in the Windows Drivers development section.
BCDEdit /set (Windows Drivers)
To use BCDEdit you have to be running from a elevated command prompt as a local administrator. For the purposes of this post I am going to use a groupsize of 2.
After changing the BCD, it is necessary to restart the machine for the configuration changes to take effect to the configuration.
Disclaimer: This is not something you should do on a production SQL Server and this is only something that should be used for testing and/or learning about SQLOS on a non-NUMA hardware machine.
After rebooting the server, if we look at the Server Properties in, we will have four NUMA nodes, each with two logical processors assigned to it.
Looking at the DMVs in SQL Server will also show the changes to how SQLOS started up and configured the instance.
Additionally, the Performance Counters in PerfMon for the Buffer Nodes we can see memory usage information per node:
Keep in mind this is all false information, but you can really learn a lot about SQL Server and perform tests of behaviors under NUMA using this method.