在安装了具有 Server + Cal 许可模式的 SQL Server Enterprise 2012 后，在一台具有 2 个处理器（每个处理器有 16 个内核，不涉及超线程）的计算机上，服务器负载极重，第一个处理器上的 16 个内核未得到充分利用，第二个 CPU 上的前 4 个内核利用率很高，而最后 12 个内核根本没有使用（因为此 SQL Server 版本有 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 开始在其识别的所有核心上均匀分配负载？
感谢任何能够回答这些问题的见解和/或链接，可能有助于我更好地理解如何理解正在发生的事情。
答案1
性能不均衡可能是 20 核限制与 SQL Server 在 NUMA 机器上调度线程的方式相结合的结果。不幸的是，SQL Server 2012 在决定使用哪 20 个核心时没有使用任何智能，导致每个 NUMA 节点的核心数量不平衡。如果 32 个核心分布在 2 个 NUMA 节点上，您最终可能会得到 16/4 的分割。这是有问题的，因为 SQL 将尝试以循环方式在 NUMA 节点之间平均平衡活动（假设您没有强制使用资源管理器的亲和性）。
在您的例子中，1/2 的负载分配给 4 个核心，1/2 分配给 16 个核心。4 核节点上的瓶颈实际上起到了节流阀的作用，将机器的容量限制为 2x 4 核 = 8 核 = 25% 的 CPU 使用率。
一旦升级到核心版本，sql 就会利用 2 个 numa 节点（16/16 分割）上的所有 32 个核心。性能得到改善，等等。
可以提高性能的一个选项是利用 SQL Server 资源管理器将大部分工作负载关联到一个 Numa 节点。例如，您可以创建一个资源池 WEB_APP，并将其关联为仅在 16 核 Numa 节点上运行。分配给 WEB_APP 池的负载可以利用 50% 的服务器容量，加上 4 核节点剩余的 12.5% 容量。
另一个选择是将 SQL 服务器可用的核心限制为每个 Numa 节点 10 个。