SQL SERVER对NUMA的支持

【NUMA介绍】

目前，CPU主频速度和CPU的个数增长得很快。但是CPU访问内存的时候，速度依旧跟不上。虽然我们提出了L3 Cache这个概念，但并不能完全解决问题。CPU访问内存速度很慢，依然是我们的瓶颈。为了更好的解决这个问题，工业界引入了NUMA概念。

NUMA 的架构可以如下:

上述结构中，我们有两个NUMA结点。每个NUMA结点有一些CPU, 一个内部总线，和自己的内存，甚至可以有自己的IO。每个CPU有离自己最近的内存可以直接访问。所以，使用NUMA架构，系统的性能会更快。在NUMA结构下，我们可以比较方便的增加CPU的数目。而在非NUMA架构下，增加CPU会导致系统总线负载很重，性能提升不明显。

每个CPU也可以访问另外NUMA结点上的内存，但是这样的访问，速度会比较慢。我们要尽量避免。应用软件如果没有意识到这种结构，在NUMA机器上，有时候性能会更差，这是因为，他们经常会不自觉的去访问远端内存。导致性能下降。

NUMA通常在有硬件或软件之分。下面分别对它们进行介绍。

【硬件NUMA】

硬件NUMA是在硬件层面上得以支持。我们怎么才能知道我们的机器是否有硬件NUMA呢? 最好的办法是问硬件供应商了。但是如果我们想知道我们的机器有多少个NUMA结点，可以在SQL Server Management Studio下用如下的查询，看能返回几个NUMA结点。

SELECT DISTINCT memory_node_id FROM sys.dm_os_memory_clerks

或者，我们可以查看SQL Server的错误日志， 如下面的错误日志表明，我们的系统有两个NUMA结点。

从 SQL Server 2000 SP3 以后，SQL Server的设计会意识到NUMA架构，内存访问会尽量使用离CPU最近的内存。以提高性能。

【软件NUMA】

如果硬件本身不支持NUMA, 我们可以在软件层面上，设置NUMA, 如我们有4个CPU, 设成两个NUMA NODE, 一个Node占用CPU 0x11 (二进制编码), 另外一个Node占用CPU 0x1100 (二进制编码).  那么，我们可以在注册表上，做如下修改，以SQL Server 2008为例:

加了上面的注册表后，重新启动SQL Server, 我们就会发现，SQL Server 会认为有两个NUMA结点。如下面的SQL 错误日志所示:

软件NUMA只是对CPU进行分组，并不会改变内存，对于内存来讲，还是只有一个结点，所以两个NUMA结点，访问的都是同一块内存。我们增加软件NUMA结点的好处在于，SQL Server会针对每一个软件NUMA结点，多一个LazyWriter的线程，如果我们的系统在LazyWriter上是性能瓶颈的话，引入Software NUMA能提升性能。

【连接】

SQL Server 不仅仅在引擎上支持NUMA, 而且在连接层面上也支持NUMA。如果没有在连接层面上对NUMA进行设置的话，那么每一个连接进来，SQL Server会根据round-robin方式，选择NODE 进行处理。在NODE内部，SQL Server会选择CPU负载最低的一个CPU进行处理。这种方法的缺点是，有可能某一个NODE内的所有CPU都很忙，但是另外一个NODE内的所有CPU都很空。导致资源不均衡。这种情况下，使用NUMA架构性能反而会下降，还不如使用非NUMA架构。系统能均衡分配CPU资源。

如下图所示，我们用round-robin方式，可能NUMA NODE0会非常繁忙，而NUMA NODE1会非常空闲，系统资源不能充分利用。重要的连接可能会被分配到NODE0, 导致不能得到及时处理，性能受到影响

为此，在连接上，我们可以做设置。对于重要的操作，我们使用端口1450, 该端口会绑定NUMA结点0, 1, 2, 而对于不重要的操作（可能需要耗费大量资源，但不重要的），我们使用端口1433, 该端口会绑定NUMA结点3, 这样，不重要的操作不会对重要的操作在性能上有所影响。

如何设置端口对NUMA结点的绑定，我们可以在侦听的端口后面加NUMA结点信息。如我们有八个NUMA结点，如果要使用NUMA结点0, 2, 5 那么根据MASK方式，相应的数值是0x25, 或37，

在SQL Server的网络设置中，相应的网络侦听端口后面，我们可以加MASK数值，如下，这样，端口63409进来的连接，会跟NUMA结点0, 2, 5 进行绑定。

【总结】

NUMA概念的引入，能大大的提升硬件的可扩展性和处理能力。SQL Server 从硬件NUMA，软件NUMA和连接上分别对NUMA这个体系架构做了很好的支持，因此，SQL Server在NUMA架构下，在性能上，有更好的扩展。