Sql server SQL Server 2017标准，CPU/MOP设置

背景

2个物理群集节点-每个4个插槽x 20个内核（80个逻辑处理器），1TB RAM

4个Intel Xeon E7-8891，10核，20逻辑处理器

每个都有8~9个虚拟SQL Server 2017标准实例，当前的“最大并行度”MOP设置从2到4

版本信息

Microsoft SQL Server 2017（RTM-CU6）（KB4101464）-14.0.3025.34（X64）
2018年4月9日18:00:41版权所有（C）2017微软公司 Windows Server 2012 R2标准6.3上的标准版（64位） （构建9600:）

现在，我看到了来自sp_闪电战的警告

CPU调度程序脱机NULL 由于关联屏蔽或许可问题，SQL Server无法访问某些CPU核心

内存节点因关联而脱机为空 屏蔽或许可问题，某些内存可能无法使用 可用

这里有一个陷阱：4个插座或24/16芯中的较小者

当我在下面运行查询时（请参见结果）

每个节点上的任务管理器CPU图总体上为20~30%（可能有24个节点被大量使用，其余部分未被使用，仅为0-1%，见图）

我试图在错误日志中搜索“许可”，但找不到这样的消息，表明只使用了一些内核

我的问题

“4个套接字或24个内核中的较小者”是否意味着我的SQL实例（每个）将只使用24个内核（尽管有80个可用）

每个实例的MOP设置应该是什么？ 他们是否足够聪明，可以“共享”可用的CPU/NUMA？e、 g.如果有80个处理器和8个实例，他们不会尝试始终使用前24个处理器

目前的数字在2-4之间，但我认为至少应该是4

当我运行一些微软计算器时，它们都说8

---

仅供参考：所有实例都设置为“自动”设置亲缘关系/IO

这是SQL 2017标准版限制中的一篇优秀文章-回答了您的问题1（是24核心限制）。另一个设置和MOP是并行性的成本阈值。国际单项体育联合会（If）可以帮助防止一切可以平行进行的事情发生，但通常是以个案为基础的。Brent Ozar在这方面发表了很多优秀的文章。虽然没有主题，但为了更好地利用资源，您确实需要虚拟化服务器。我们已经有了VMware环境，将来可能会虚拟化物理服务器，但仍然需要解决当前的CPU问题：（我正在调整每个实例上的MAXDOP设置，以监视性能变化

 SELECT * FROM sys.dm_os_schedulers --115 total
 where status LIKE '%hidden%' --32 VISIBLE OFFLINE; 34 HIDDEN ONLINE