为什么CPU在我们的8-CPU SQL Server盒子上使用如此不对称？

我注意到运行SQL Server 2008的8-CPU数据库服务器的CPU使用率根本不平衡。

下面是一个随机的一天的平均值，这是典型的，一致的不对称：

9，15，10，21，18，21，14，9

（这里只是缩略图，因为图像真的很高，但点击全尺寸的图像）

与我们的4-CPUnetworking服务器相比，这些服务器几乎都是完全平衡的，这让我觉得很奇怪。

现在，这是一个专用的服务器，所以运行它的唯一的东西是SQL Server 2008（和内置的全文索引，我们使用相当多），所以我不知道为什么CPU的使用会是如此不对称 。思考？

你的文件/文件组是如何设置的？

我会抄袭自己：

还有一个关于IO的想法：我们小心地将我们最常用的表格设置在文件组中，其中包含多个文件。其中一个增强的性能是SQL将请求发送到文件组中的每个文件 – 所以如果BigOverUsedTable在FileGroup1上，而FileGroup1在其中有四个文件，而你的数据库有8个内核，它实际上会使用四个内核来做“select大数字从BigOverUsedTable嘎吱嘎吱的查询“ – 否则，它将只使用一个CPU。我们从这个MSDN文章中得到了这个想法：

http://msdn.microsoft.com/en-us/library/ms944351.aspx

从TFA：

“文件组使用并行线程来改善数据访问，当顺序访问表时，系统为每个文件并行创build一个单独的线程，当系统对包含四个文件的文件组中的表执行表扫描时，它使用四个单独的线程来并行读取数据，一般来说，在不同的磁盘上使用多个文件可以提高性能，文件组中的文件太多会导致太多的并行线程，造成瓶颈。

由于此build议，我们在8核心机器上的文件组中有四个文件。它工作得很好。

编辑：现在有另一个（可能）更好的答案。这些图表是按比例缩小的 – 如果仔细观察，每个处理器实际上是大约20％的加载，因为uzbones指出。

编辑：我们实际上可以告诉使用多个文件文件组有帮助，因为我们没有把我们所有的表格放在四个文件的文件组中。 “单个文件”文件组上的大查询只使用一个CPU，但在四个文件文件组中的表上的查询命中4个CPU。

所有的比例都不同，除了4个图表上的峰值，平均值大概是10-25％。

看一下这个：

http://blogs.technet.com/mat_stephen/archive/2005/02/02/365325.aspx

SQL可能只能写入less数文件，每个处理器正在使用每个文件。

我首先检查的东西是司机。 networking组合和iSCSI MPIO驱动程序坚持特定的内核，我遇到了很多问题。我敢打赌，这里不是问题，因为它看起来像是发生在4个内核上 – 我通常只能看到2个内核。我会问，看看有没有人看到这个广泛。

我也在NUMA盒子里看到有一个内存不匹配的情况 – 也就是说有一半的核心连接到16gb的内存，其他的连接到8个。如果你想看看关于这个的一些有趣的信息，Google for IBM x460 NUMA。 460和相关型号可以让你将几台服务器连接起来，形成一个大型的铁杆 – 与放大的博客相关。他们真棒机器。

因为刷新CPUcaching非常昂贵，所以内核不惜一切代价尽力避免。

（注意：至lessLinux是的;如果Windows没有相同的行为，我会感到惊讶）