SQL Server 2005-多处理器使用

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

---

我们看到的是标准SQLServer2005集群行为吗？我假设所有16个处理器将在任何时候都被使用，尽管情况似乎并非如此。这是我们可以调的吗？或者这是预期的行为？SQL server是否能够利用所有16个处理器呢？

您确定您没有在其他地方遇到瓶颈吗？关于IO？如果没有硬数据，很难确定，但我怀疑问题在于，您现在的IO限制或内存限制比CPU限制更多，4个处理器足以跟上您真正的瓶颈

---

我的理由是，如果有一些配置问题使您只能使用4个CPU，您根本不会看到它溢出到第5和第6个处理器。

即使考虑到IO瓶颈，我要检查的是您是否设置了处理器亲和力，maxdop设置是什么，无论是SMP还是NUMA，都会影响您希望设置的maxdop

---

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

< P>我会考虑你的尽职调查，并验证CPU消耗属于SQLServ.EXE过程，所以我们不会在这里追赶一个红色鲱鱼。如果没有，请通过检查进程\%处理器性能计数器，确保sqlservr.exe占用了CPU

您需要了解SQL Server CPU调度模型，如中所述。SQL Server通过将每个请求分配给工作进程（）运行的任务（），将请求（）分布在调度程序（）上。辅助线程由操作系统线程或光纤（）支持。大多数请求（发送到SQL Server的批处理）只生成一个任务，但有些请求可能生成多个任务（并行查询是最臭名昭著的）

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

• 超阅读。如果启用了超读，请将其关闭。SQL Server和超线程读取
• 糟糕的司机。确保安装了正确的系统设备驱动程序（如主板等）

还要确保您的SQL 2005至少是SP2级别，最好是最新的SP和所有应用的CU。Windows也是如此（您运行的是Windows 2003还是Windows 2008？）

---

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

谢谢您的回复！我要找出我们的MAXDOP设置是什么。此外，集群指的是2台物理服务器，每个服务器有16个处理器。除非运行少量无法并行且非常昂贵的查询，否则不应看到其中4个进程达到高cpu，而其他进程处于空闲状态。如果您运行更多的查询/查询是并行的，那么负载将更加平衡。我们的大部分查询都非常快，尽管有一些查询速度较慢。因此，对于大量相对快速的查询，您可能会认为其他处理器的利用率会更高？我可能会认为它会更平衡，但这取决于同时运行的数量和持续时间，如果一次只运行4个，而没有并行性，那么一次只会运行4个cpu。这实际上取决于查询/并行性/工作负载，如果没有细节，就不可能定义。我担心您会说您需要细节：）不幸的是，这需要DBA做一些工作-但感谢您在这一点上的建议！我应该澄清一下——我们目前没有瓶颈。我只是想确保当我们看到高负载（因为有一些新的数据库密集型功能被添加到应用程序中）时，所有处理器都将被使用。我同意，我只是想知道这是否是SQL Server的标准操作过程。也就是说，随着使用量的增加，它是否会慢慢地让更多的处理器加入竞争？我认为负载会被平均分配，所以我只想确认我们看到的行为是设计的。有些人对每个cpu使用SQL Server许可证，因此这种行为是为了节省他们的钱。是的，我最初考虑过这一点，但据我所知，我们使用的是无限制的cpu许可证（不知道这要花多少钱？：）这太棒了！非常感谢这些链接！我在到处寻找一个全面的CPU调度图或其他东西。你会在Slava的博客中找到很多内部描述，我在想，正如你所说的，可能是操作系统导致了问题，它只是给四个处理器分配了线程。检查sys.dm_OS_schedu