eG Help

Microsoft SQL Server is non-uniform memory access (NUMA) aware. As clock speed and the number of processors increase, it becomes increasingly difficult to reduce the memory latency required to use this additional processing power. NUMA architecture provides a scalable solution to this problem. The SQL Server has been designed to take advantage of NUMA-based computers without requiring any application changes. This database server groups schedulers to map to the grouping of CPUs, based on the hardware NUMA boundary exposed by Windows. For example, a 16-way box may have 4 NUMA nodes, each node having 4 CPUs. This allows for a greater memory locality for that group of schedulers when tasks are processed on the node. With the SQL Server you can further subdivide CPUs associated with a hardware NUMA node into multiple CPU nodes. This is known as soft-NUMA. There is one SQL Server memory node for each physical NUMA node. When a thread running on a specific hardware NUMA node allocates memory, the memory manager of SQL Server tries to allocate memory from the memory associated with the NUMA node for locality of reference. Similarly, buffer pool pages are distributed across hardware NUMA nodes. It is more efficient for a thread to access memory from a buffer page that is allocated on the local memory than to access it from foreign memory.

To understand the local vs. foreign memory distribution in SQL Server better, assume that the computer has 16 gigabytes (GB) of memory. Other applications including Windows have consumed some of the memory from each node, SQL Server has assigned some memory for its processes outside of the buffer pool, and SQL Server has 10 GB of memory to assign to the buffer pool. The buffer pool memory is divided among four physical NUMA nodes, N0, N1, N2, and N3, each with the following local memory available:

In the above configuration, all nodes will eventually allocate and use 2.5 GB of memory; however, node N0 will end up with 1.0 GB of its own memory, and 1.5 GB of memory from other nodes.

The MsSqlPageTest reports information about buffer pool page distribution for each NUMA node on MSSQL Server.

This test reports measures only for Microsoft SQL Server version 2005 and above.

Measurement	Description	Measurement Unit	Interpretation
Database_pages	The number of pages that are currently in the buffer pool with database content	Number
Foreign_pages	The number of pages that were currently received from other NUMA nodes	Number	If the SQL server is running on non-NUMA hardware, then the value of this measure will be 0. Foreign pages will not be used during ramp-up because they can frequently be transferred to the owning node and become local to that node. When the value of max server memory is reached, some nodes may have foreign memory, but once the memory target is achieved, the buffer pool will treat local and foreign memory identically. For example, under memory pressure, the buffer pool will not make any effort to free up foreign memory pages before local memory pages.If the value of this measure increases consistently, it indicates that local memory on the node is inadequate. If the value of this measure dips consistently, it is indicative of insufficient memory on the node. You might want to consider resizing the buffer pool in this case.
Free_pages	The total number of pages that are currently free on this NUMA node	Number	If the value of this measure dips consistently, it is indicative of insufficient memory on the node. You might want to consider resizing the buffer pool in this case.
Page_life_expectancy	The number of seconds a page currently stayed in the buffer pool without references	Seconds
Stolen_pages	The number of pages that were currently used for miscellaneous server purposes (stolen from the buffer pool) on this node	Number
Target_pages	The ideal number of pages in the buffer pool on this node	Number
Total_pages	The total number of committed pages that currently exist in the buffer pool on this node	Number