Using NUMA Nodes with SQL Server

Question

I have a question to understand better how NUMA nodes help in SQL Server:

In our current set up, we have 4 NUMA nodes with 20 cores and hyper threading enabled, making a total of 40 logical processors. With memory of 400 GB, each NUMA gets 100 GB each.

It is a physical server with SQL Server 2012 Enterprise (core based licensing) on Windows 2012 R2 Standard. It has 4 sockets with 10 cores per socket and 20 logical processors per socket total 80 from error log what I see.

My understanding is maybe having 4 NUMA nodes might not perform better if we move (future SQL refresh to 2017/19) with same number of NUMA rather than I prefer 2 NUMA.

Why I am saying this because I think with 2 NUMA 400 GB will be allocated as 200 GB in each.

Therefore my understanding is it might perform better or its best to have this configuration based on how queries are switching between nodes for memory. Yes we are seeing some memory issues, I know there are other related issues which we are working but this question is more specific to NUMA set up for SQL Server.

Could someone please share their experience or may be provide more insight as I might be thinking wrong here with the belief query will have to less swapping here and there on 2 NUMA in comparison with 4 NUMA?

Is there a way or a query I can check if queries are spending time in swapping over two different NUMAs for memory and can be an issue?

Is there a way we can measure if two nodes might work better than four nodes for future design (cross-node memory access)?

Answer 1

Its a physical server on windows 2012 R2 standard. It has 4 sockets with 10 cores per socket and 20 logical procesors per socket total 80 from error log what i see. Its SQL2012 trying to move to 2017

Ok. The memory on this box is seperated into 4 seperate nodes, each attached to a single socket. SQL Server will use memory across all the sockets, and since much of SQL Server memory is used for caching database pages and query plans, there will be significant amounts of cross-node memory access. And that's OK. Query memory grants will be allocated on the local node for the worker running the task.

SQL Server has several resources it allocates per NUMA node, and for SQL Server 2016+ will automatically subdivide large NUMA nodes with the Automatic Soft-NUMA feature.

So on the one hand there's nothing you can do about the physical configuration of the server memory, and on the other there's nothing you need to do as SQL Server will automatically configure itself to use the NUMA nodes most effectively.

Is there a way we can measure if 2 nodes might work better than 4 nodes for future design ?

Basically fewer nodes is better, but there's a limit to how many cores and how much RAM you can put on a single NUMA node.

Most of the cross-NUMA node memory access should be in the Buffer Pool, which you can track with a performance counter:

SQL Server: Buffer Node Remote Note page lookups/sec Indicates the number of lookup requests from this node which were satisfied from other nodes.