![SQL Server 2005 性能问题](https://linux22.com/image/507481/SQL%20Server%202005%20%E6%80%A7%E8%83%BD%E9%97%AE%E9%A2%98.png)
我们正在迁移到功能强大的新 SQL Server(12GB RAM、2 个 4 核 CPU、12 个 15k rpm 驱动器、Gbit 网络)。我们将驱动器分为 4 个分区,分别用于操作系统、数据、日志和全文索引文件。
问题如下:我正在运行一个作业,该作业从单线程控制台应用程序执行 36k 次搜索(表和全文连接的组合)。但服务器并没有给我们的服务器带来负担,而是记录了大约 5% 到 7% 的 CPU 负载,而不是我们旧服务器上的 +-60%。
从仪表板报告来看,我们唯一遇到的等待是偶尔的网络 IO 等待 - 但这种情况时有时无。所以看起来 SQL Server 正在限制我们的连接?
有人可以解释一下这个问题吗?
答案1
好吧,您可以尝试运行 Perfmon 和 SQL Profiler 来更深入地了解这一点。但首先,请告诉我们更多关于您的驱动器配置的信息。您说您有 12 个驱动器,分为 4 个分区。这是否意味着您制作了一个大的 RAID 阵列并将其分成 4 个实际的操作系统级分区,还是您制作了 4 个 RAID 容器,每个容器都有一个操作系统分区?前者是导致性能不佳的良方。
答案2
据我所知,SQL Server 2005 中唯一一个因任何原因限制连接的版本是 Express,而且只有在同时有“很多”连接时才会限制连接。不太可能有人在强大的服务器上安装 Express,也不可能单线程控制台应用程序有多个同时连接。
如果您的查询未并行化,则每个查询将仅在该机器的八个(2x4)核心中的一个上运行,从而实际上浪费了其他七个核心。
如果没有其他瓶颈(换句话说,您的查询所需的所有数据都缓存在 RAM 中,并且没有其他东西阻止查询),您的查询将占用一个核心的 100%。系统上一个“核心”的负载为 12.5%。如果您添加一点磁盘活动,这与您所看到的情况很接近。
当旧服务器达到 60% 时,可能是因为某种原因,旧服务器并行化了(至少一些)查询,而新服务器没有并行化任何查询。
我会使用 Perfmon 查看每个核心处理器的负载。我猜你会发现其中一个核心的负载为 100%,或者非常接近 100%。你可能会发现“繁忙”的核心从一个核心变为另一个核心。如果所有核心都同样繁忙,那么就会发生一些奇怪的事情。在这种情况下,我肯定会寻找数据库文件 I/O 上的等待情况。有一个 DMV 可以解决这个问题。
我还会使用 SSMS 查看应用程序执行的查询的至少一个示例的查询计划。有时,事情会突然出现(“嘿,那个索引去哪儿了?我以为我们在升级后把它放回去了”,或类似的东西。)。
总结:
- 确保您的索引统计信息是最新的。(如果可以,最简单的做法就是重新索引所有内容。)如果您在升级过程中从 SQL2000 升级到 SQL2005,这一点尤为重要。
- 查找阻塞。如果发现阻塞,要问的问题是“为什么这在旧系统上有所不同?”和“我现在如何最大限度地减少阻塞?”
- 如果您需要查询并行化,请确保友好的 DBA 没有将服务器的 MAXDOP 配置设置为 1(默认值为 0)。这可以在服务器级别配置。请参阅最大并行度无论设置如何,您都可以在查询中使用 MAXDOP 关键字强制查询并行化(或不并行化)。
- 查看这 36 个查询的查询计划。调整您的查询和表/索引。
- 重新设计单线程控制台应用程序,以在(可能)其他线程上的不同连接上运行不同的查询,以便您可以一次运行多个查询。 (这显然是最复杂和最不可取的事情,假设您甚至有源代码。)