小编Aar*_*ron的帖子

我正在跟踪 SQL Server 活动监视器中报告的处理器百分比与资源监视器中使用的总处理器百分比之间的显着差异。我看到两者之间大约有 50% 的差异，而活动监视器总是更高。

系统规格：

• SQL Server EE 2008 R2
• 视窗 2008 R2
• 裸机
• 96 个核心，无处理器关联集（4 个物理插槽，每个 12 个核心，启用超线程）
• 768 GB 内存
• 主动/被动集群
• SSD 的直连存储

什么会导致这种差异？

我应该看哪一个？

更新：

我看到资源监视器将其分为不同的类别，但是“CPU - 总计”图表不会显示机器上的所有 CPU 使用情况吗？

任务管理器性能选项卡显示它与活动监视器之间的相同差异。

• 活动监视器刷新 1 秒。

活动监视器没有看到每个核心都是超线程的，这会不会有问题？不确定 SQL Server 如何看待所有 96 个内核。

2018 年 6 月 28 日更新

即使在迁移到 AWS 并将操作系统更新到 Server 2012 R2 之后，SQL Server 2008 r2 活动监视器仍然与任务管理器显示的内容相差甚远。下面的屏幕截图来自刚刚执行的负载测试。两个指标之间存在明显的 20% 差异。即使任务管理器报告总体 CPU 刚刚超过 55%，SQL 活动监视器也被锁定在 100%。来自 AWS Cloud watch 的指标显示的结果与 Task Manager 相同，因此我有两个数据指标与第三个甚至不在球场上相关。

更新的系统规格： 系统规格：

• SQL Server …

我正在一台机器（不是虚拟机）上运行 2008r2 EE 版本的 SQL Server，该机器具有 4 个插槽的 Intel\xc2\xae Xeon\xc2\xae 处理器 E7-8880 v3，并启用了超线程。我正在尝试验证处理器和 I/O 的关联性，确保我的应用程序可以在更少的内核上运行，因此我手动设置处理器和 I/O 以平衡使用情况，这样就不会同时使用一个内核运营。然而，一旦我到达第三个 NUMA 节点（即 CPU 64），我只能设置处理器关联性的使用，并且 I/O 关联性会变灰。

该文档有点令人困惑，因为它引用了 CPU 而不是核心/处理器，但确实引用了必须设置affinity64 选项来控制处理器 33-64，即使在处理器方面似乎可以在即使 I/O 部分不是 UI，也是如此。我没有发现任何内容表明 I/O 只能绑定到系统的前 64 个核心。

我有另一个物理盒子，有两个 CPU 插槽，有 16 个物理核心，启用超线程，每个 CPU 提供 32 个核心。在此服务器上，我能够控制所有核心，无论它们是否是超线程。

为什么我无法在所有 128 个可见核心上设置 I/O 关联性？和超线程有关系吗？