SQL Server 2005 -多处理器使用率

Question

我们有一个16处理器的SQL Server 2005集群。查看CPU使用率数据时，我们发现大多数情况下，16个处理器中只有4个处理器被利用过。然而，在高负载时期，偶尔会使用第5和第6个处理器，尽管永远不会接近其他4个处理器的利用率。我担心在非常高负载的时期，不是所有其他处理器都被利用，我们的性能将会下降。

我们看到的是标准的SQL Server 2005群集行为吗？我假设所有16个处理器都会在任何时候都被利用，尽管事实并非如此。这是我们可以调优的东西吗？或者这是预期的行为？如果到了那个地步，SQL server能利用全部16个处理器吗？

Answer 1

我认为您已经做了尽职调查，并验证了CPU消耗属于sqlservr.exe进程，所以我们在这里不是在追逐转移注意力的问题。如果不是，请检查Process\% Processor performance计数器，确保sqlservr.exe占用了CPU。

您需要了解SQL Server CPU计划模型，如Thread and Task Architecture中所述。SQL Server通过将每个请求分配给由辅助进程(sys.dm_exec_requests)运行的任务(sys.dm_os_tasks)来跨计划程序(sys.dm_os_schedulers)分布请求(sys.dm_os_workers)。worker由OS线程或纤程(sys.dm_os_threads)支持。大多数请求(发送到SQL Server的批处理)只产生一个任务，但有些请求可能会产生多个任务(最臭名昭著的是并行查询)。

SQL Server2005计划的正常行为应该是跨所有计划程序均匀分配任务。每个调度器对应于一个CPU核心。结果应该是所有CPU核心上的负载均匀。但我在实验室中见过几次您所描述的问题，当物理工作负载仅在几个CPU上分布不均匀时。您必须了解，SQL Server并不控制其工作线程的线程关联，而是依赖OS关联算法来确定线程的位置。这意味着，即使SQL Server将请求分散到16个调度程序中，操作系统也可能决定仅在4个核心上运行线程。与此问题相关的是，有两个问题可能会导致或加剧此行为：

• Hyperthreading.如果启用了超线程，请将其关闭。SQL Server和超线程should never mix.
• Bad驱动程序。确保您安装了正确的系统设备驱动程序(对于主板之类的设备)。

还要确保您的SQL2005至少是SP2级别的，最好是最新的SP和应用的所有CU。Windows也是如此(你运行的是Windows2003还是Windows2008？)

从理论上讲，这种行为也可以用一个非常特殊的工作量来解释，即。SQL只看到很少的没有并行选项的非常长的、对CPU要求很高的请求。但这将是一个极端的倾斜负载，我在现实生活中从未见过这样的事情。

Answer 2

即使考虑到IO瓶颈，我也会检查你是否设置了处理器亲和力，你的maxdop设置是什么，它是SMP还是NUMA，这也应该影响你可能希望设置的maxdop。

当您说您有一个16个处理器的集群时，您是指集群中的2个SQL服务器，每个集群有16个处理器，或者2个8路SQL服务器？

Answer 3

你确定你不会在其他地方遇到瓶颈吗？也许是在IO上？