在使用Server + Cal许可证模型安装SQL Server Enterprise 2012之后，在具有两个每个都有16个内核的处理器（并且不涉及超线程）的计算机上，并且将服务器置于极其繁重的负载下，第一个处理器上的16个内核的利用率非常低，第二个CPU上的前4个内核被大量使用，最后12个内核根本不使用（因为这个sql服务器版本的内核限制为20个）。 总CPU利用率显示为25％左右。 不幸的是，即使如果任务在20个内核上均匀分配，服务器的性能也会非常差，但是这种性能不会太差。
Windows Server在ESX Server下的VMWare虚拟映像上运行，但是所有的CPU都被分配给了Windows服务器。
我们试着改变关联设置（例如，将大多数核心分配给CPU，其他核心分配给I / O），但是这并没有帮助解决性能问题。
将产品版本升级到SQL Server Enterprise Core 2012不仅使SQL Server能够利用第二个处理器上先前未使用的12个内核，而且还可以在所有处理器上实现更均匀的任务分配。 为了解决积压的问题，CPU利用率跳升到90％左右，一旦被赶上后下降到33％左右，但是从最新的版本失败后，性能大幅提升，性能问题也随之消失。
我想知道是否有人知道什么可能会导致SQL Server不均匀地分配负载，几乎完全依赖于第二个处理器的前12个核心处于空闲状态的4个内核，并且只在第一个内核的16个内核中分配了几个任务处理器。 另外，有没有什么办法可以让我们更平均地分配20个内核的负载，而不用进行产品版本升级呢？
这个问题的另一面是产品升级做了什么，导致SQL Server开始在所识别的所有核心上平均分配负载？
感谢任何见解，以回答这些问题和/或链接，可能会帮助我更好地了解如何理解发生了什么事情。
不均衡的性能可能是20核心限制与sql server在NUMA机器上调度线程的方式的组合。 不幸的是，SQL Server 2012在决定使用哪20个内核时并不使用任何智能，导致每个NUMA节点的内核数量不平衡。 跨2个NUMA节点的32个核心，你可能会最终以16/4分割。 这是有问题的，因为SQL会尝试以循环方式跨NUMA节点平均分配活动（假设您不强制与资源pipe理器build立关系）。
在你的情况下，1/2负载分配给4个核心，1/2到16个核心。 4核心节点的瓶颈实际上起到节stream的作用，将机器的容量限制为2x 4核心= 8核心= 25％的CPU使用率。
一旦你升级到核心版本，然后SQL利用所有32个核心跨2个numa节点（16/16分裂）。 性能提高等
一种可以提高性能的select是使用sql server资源pipe理器将大部分工作负载关联到一个numa节点。 例如，您可以创build一个资源池WEB_APP，并将其关联到仅在16个核心numa节点上运行。 分配给WEB_APP池的负载可以利用服务器容量的50％，以及来自4核心节点的剩余12.5％的容量。
另一种select是将sql server可用的内核限制为每个numa节点只有10个。