什么会导致长时间的查询持续时间而不使用高资源？

Question

提前：对不起，问题的长度......无法在细节和简洁之间取得适当的平衡。

我们的 Web 应用程序的数据库服务器存在问题，其中应该（并且通常会）在很短的时间内（< 10 毫秒）运行的查询在随机情况下需要 1 到 30 秒的时间来执行 - 没有明显的图案。根据我们的分析器跟踪，其中一些甚至是“无所作为”的查询，例如"exec sp_reset_connection"（通常在 0ms 内运行；观察到 3~6s 的峰值）"SET NO_BROWSETABLE ON"，等等。一些示例是：

SELECT * FROM [Localisation].[TimeZoneRule] WHERE [Name] = 'EU'

其中TimeZoneRule5 列大约有 500,000 行。有一个代理主键和一个索引Name。通常需要 0.97ms，在 11s 达到峰值。表永远不会写入（在上线之前预先填充）。Profiler 将其记录为占用 0-15 个 CPU、18-25 个读取、0-1 个写入（不知道为什么要写入）。

UPDATE [Core].[User] SET [LastUsed] = GETUTCDATE() WHERE Id = '<uid>'

其中User大约 10 列（其中之一是 Xml 列）有大约 30,000 行。Id是集群主键。表定期写入和读取。通常需要10~20ms，在26s达到峰值。Profiler 将其记录为占用 0 个 CPU、15-36 次读取、0-1 次写入。

INSERT INTO [Log].[Session] (ASPSessionId, Start, ClientAddress, ClientSoftware, ProxyAddress, ProxySoftware)
   VALUES(<number>, GETUTCDATE(), '<ipv4address>', '<User agent string>', '<ipv4address>', '<proxy software name (if present)>')

其中Session大约 8 列中有大约 1,000,000 行。有一个代理主键（身份）和一个关于 的索引ASPSessionId。表定期写入，但很少读取（仅由我们直接从 SSMS 读取）。通常需要15~150ms，在5s达到峰值。我手头没有它的配置文件记录，但从内存来看，CPU 大约为 0，读取和写入各在 0 到 100 之间。

我们使用的设置是以Dell 2950 为原理（2 个4 核xeon 2.6，16Gb RAM）和Dell 6850 作为镜像（4 个HT Xeon 3.2，8Gb RAM）的镜像设置。两者都运行 SQL 2005 SP4 64 位。有问题的数据库不是特别大，大小约为 16Gb。主要有 6 个 SAS 磁盘，分为 3 个 RAID-1 卷；一份用于System + Page + TempDB，一份用于数据库的MDF，一份用于事务日志+每小时日志备份+每日DB备份。我知道日志情况远非最佳 - 在磁盘 IO（见下文）和数据安全方面。

到目前为止，我们认为我们已经消除了：

• 镜子。我们将服务器分开，并使用其中一个运行（然后切换到另一个），但性能问题仍然存在。
• 由于锁（*）而阻塞。TimeZoneRule从来没有写过，据我估计，它永远不应该有一个排他锁。此外，我们已经检查了跟踪，在很多情况下，“问题查询”是唯一运行的 - 唯一的其他活动是其他连接断开
• 索引不好。由于读取和 CPU 的数字较低，这表明 SQL Server 正在有效地使用索引。
• 磁盘 IO。PerfMon 显示数据文件驱动器（但仅限于该驱动器）的一些奇怪数字 - 虽然数据读/写速率似乎很少超过 32KB/s，但当前磁盘队列长度在 2-5 秒的持续时间内飙升至 215 左右，大约为 45 -60 分钟间隔，没有固定模式。但是，这些与查询性能不佳的时间无关。其他两个驱动器 [system + page + tempdb] 和 [log + backups] 的磁盘队列长度从不超过 3。

(*) 我们已经尝试使用分析器来捕获与锁定获取相关的事件，但跟踪膨胀到无法读取的程度，更糟糕的是，Web 应用程序停止运行。

不是 DBA，我们很快就没有想法了。谁能想到我接下来应该考虑看的任何东西或我愚蠢地错过的任何东西？

Answer 1

当您运行 SQL 2005 时，您可以获取 SQL Profiler 数据并将其与 Perfmon 数据进行比较，看看是否可以看到相关性。这是通过使用常规技术将跟踪数据和性能监控数据保存到文件中来完成的。然后在探查器中打开 SQL 探查器跟踪，然后文件菜单中的选项之一将是“导入性能数据”。这将让您选择一个查询并查看计数器当时正在做什么（或接近它，具体取决于您的 perfmon 收集间隔）。

磁盘队列峰值从来都不是好事。尤其是那么高。当队列达到如此高的水平时，您推送到磁盘的 IO 是多少？基本上，您不希望磁盘队列高于 (2*n)，其中 n 表示阵列中的磁盘数量。由于您使用的是 2 磁盘 RAID 1 n=1 （因为您只能获得单个磁盘的速度）。

在 perfmon 中有一个计数器，它是每次读取的秒数和每次写入的秒数。当查询开始需要很长时间运行时，这些计数器会是什么样子。平时呢？（任何超过 0.02 秒的时间都是不好的。）预计页面预期寿命是多少？（任何低于 300 秒的时间通常都是不好的，但这可能会有所不同。） SQL Server 缓存命中率是多少？（任何低于 ~97% 的值通常都是不好的。我喜欢我的高于 99.9%。）