SQL Server 长时间运行的查询需要数小时但使用的 CPU 较低

Posted 2023-02-25

【中文标题】SQL Server 长时间运行的查询需要数小时但使用的 CPU 较低

【英文标题】：SQL Server long running query taking hours but using low CPU

【发布时间】：2015-05-21 06:08:10

【问题描述】：

我在具有 32 GB RAM 和 8 个 CPU 内核的专用服务器上运行 Windows Server 2012 下的 SQL Server 2012 中的一些存储过程。 CPU 使用率始终低于 10%，而 RAM 使用率始终为 80%，因为 SQL Server 分配了 20 GB（32 GB）。

有些存储过程有时需要 4 小时，而在其他日子，使用几乎相同的数据，需要 7 或 8 小时。

我正在使用限制最少的隔离级别，所以我认为这不应该是一个锁定问题。数据库大小约为 100 GB，最大的表大约有 500 万条记录。

这些进程有批量插入、更新和删除（在某些情况下，我可以使用 truncate 来避免生成日志并节省一些时间）。我正在一个表中进行一些全文搜索查询。

我可以完全控制服务器，因此我可以更改任何配置参数。

我有几个问题：

是否有可能提高查询的性能使用 并行性？ 为什么 CPU 使用率这么低？ 配置 SQL Server 的最佳做法是什么？ 审计服务器的最佳免费工具是什么？我试过一个 来自 Microsoft 的称为 SQL Server 2012 BPA 但报告总是 清空，没有任何警告。

编辑： 我检查了日志，发现了这个：

2015 年 3 月 18 日 11:09:25，spid26s，未知，SQL Server 遇到 82 次 I/O 请求发生时间超过 15 秒才能完成文件 [C:\Program Files\Microsoft SQL Server\MSSQL11.HLSQLSERVER\MSSQL\DATA\templog.ldf] 在数据库 [tempdb] (2) 中。操作系统文件句柄为 0x0000000000000BF8。最近的long I/O的偏移量为：0x00000001fe4000

【问题讨论】：

你的问题很复杂，你的性能问题可能有很多原因。CPU使用率很低可能是因为内存已满，服务器正在交换磁盘。 （这是我的猜测）

你应该首先看看你是否可以改进查询。看执行计划。您可以使用 SQL Server Profiler 准确查看服务器上发生的情况。您甚至可以将执行计划添加到分析器，这样您就可以知道哪些查询太慢了。

您也可以使用 SQL Sentry Plan Explorer（免费）来调查执行计划并在此处发布（必要时匿名）：sqlsentry.com/products/plan-explorer/…

除执行计划外，查看表是否有索引？重建索引

您已将 20 G 分配给 SQL Server，将 12 G 分配给 OS。您是否可以将 20 G 增加到 25 或者可能是 26 G。同样的问题是开放式的，我们需要一些执行计划或在查询执行不良时等待统计数据以进一步评论。

【参考方案1】：

将最大内存提高到 24 GB。 将 tempdb 移出 C 盘并考虑多个 tempdb 文件，自动增长至少 128 Mbps 或 256 Mbps。 安装性能仪表板并运行性能仪表板报告以查看正在运行的查询并检查等待情况。 如果您对用户数据日志和 10% 的日志文件使用自动增长，请将其更改为类似于上述 tempdb 增长的内容。 使用性能仪表板检查可预测 95% 或更高改进影响的明显缺失索引。 不要理会所有反对我的建议的人。如果您做了这 5 件事，但仍然无法从性能仪表板发布一些结果，顺便说一句，这些结果是免费的。 还有一点可能会有所帮助，下载并安装 sp_whoisactive 存储过程，运行它并查看正在运行的进程。研究运行 sp_whoisactive 后发现的查询。

【参考方案2】：

查询耗时数小时，但 CPU 使用率低

您说 CPU 对大多数数据库操作都很重要。提示：他们没有。

数据库需要 IO。 RAM sin 在某些情况下有助于缓解这种情况，但最终它会运行到 IO。

你知道我在你的问题中看到了什么吗？ CPU、内存（不知何故假设 32gb 令人印象深刻）但没有关于磁盘布局的消息。

这才是最重要的。光盘，分发文件以分散负载。

如果您查看性能计数器，那么您会发现磁盘上的延迟非常高 - 因为无论您使用哪种“可悲”（在 sql server 术语中）磁盘布局，它根本无法胜任任务。

是时候开始购买了。 SSD比光盘便宜很多。你可能会说“哦，它们怎么便宜”。好吧，你不买 GB - 你买 IO。上次我检查 SSD 的成本没有光盘价格的 100 倍——但它们的 IO 是它们的 100 倍或更多。我们总是谈论随机 IO。

然后将 Tempdb 隔离在单独的 SSD 上 - tempdb 要么不做很多事情，要么做 TON，而您想看到这个。

然后隔离日志文件。

为数据库和 tempdb 制作多个数据文件（尤其是 tempdb - 尽可能多的核心）。

是的，这需要花钱。但最后 - 你需要 IO 并且像大多数开发人员一样，你有 CPU。对数据库不利。

【讨论】：

+1 供您发表评论。自从我遇到这个问题以来已经很长时间了，我按照您描述的方式解决了它。更快的 IO、分散的数据文件、日志文件和 tempdb。查询调优也有很大帮助。