我们正在迁移到一个强大的新SQL Server（12GB RAM，2个4核CPU，12 x 15k rpm驱动器，Gbitnetworking）。 我们将驱动器分为4个分区，分别是操作系统，数据，日志和全文索引文件。
问题在于：我正在运行一个作业，从单个线程控制台应用程序中执行36k次search（表和全文连接的组合）。 只有而不是征税我们的服务器，服务器注册约5-7％的CPU负载，而不是我们的旧服务器上得到的±60％。
从仪表板报告，我们收到的唯一的等待是偶尔的networkingIO等待 – 但它来了又去。 所以它似乎像SQL Server节stream我们的连接？
任何人都可以点亮这个？
那么，你可以尝试运行Perfmon和SQL Profiler来获得更多的洞察。 但是请首先告诉我们一些关于你的驱动configuration的信息。 你说你有12个驱动器分成4个分区。 这是否意味着您创build了一个大的RAIDarrays并将其分割为4个实际的OS级别的分区，或者是否制作了4个RAID容器，每个容器都有一个OS分区？ 前者是糟糕performance的好方法。
IIRC，SQL Server 2005的唯一版本，由于任何原因，扼杀连接是Express，并且它看起来“多”同时连接时只会节制。 有人在一台强大的服务器上安装Express或者一个单线程控制台应用程序有很多同时连接是不太可能的。
如果你的查询不是并行化的，那么每个查询只能在其中一个机器上运行8个（2×4）内核，这有效地浪费了其他7个内核。
没有其他瓶颈（IOW，你的查询需要的所有数据都被caching在RAM中，而且没有其他的阻塞查询），你的查询将占用一个核心的100％。 你的系统上的一个“核心值”是12.5％。 如果你添加了一些磁盘活动，这与你所看到的是密切相关的。
在旧服务器达到60％的情况下，出于某种原因，旧服务器可能会将其并列（至less是一些）查询，而新服务器不会并行查询任何查询。
我会使用Perfmon来查看每个核心处理器的负载。 我的猜测是，你会发现其中一个是100％，或者非常接近它。 您可能会发现“繁忙”的核心从一个变为另一个。 如果所有核心都同样繁忙，那么一些陌生人正在发生。 在这种情况下，我肯定会想要在数据库文件I / O上等待。 有一个DMV的。
我也会使用SSMS来查看查询计划，以查看应用程序执行的查询的至less一个样本。 有时候，事情只是跳到你身上（“嘿，那个索引去了哪里？我想我们在升级之后把它放回去了”，或者类似的东西）。
总结一下：