散列/排序溢出到 tempdb 的频率是多少？

Question

我们的企业应用程序使用 SQL Server 进行数据存储，主要是一个 OLTP 系统。但是，我们应用程序的一个重要组件会产生大量的 OLAP 工作负载。

我们对 tempdb 的写入延迟约为 100 毫秒。这种趋势发展随着时间的推移，和ALLOW_SNAPSHOT_ISOLATION关断。我们正在对此相关问题进行故障排除，到目前为止我们发现的唯一有趣的事情是有大量散列和排序溢出到 tempdb。我们推测这来自我们的 OLAP 工作负载。

题

泄漏的频率是多少？任何？多少次溢出/秒？我们的初步数据表明我们每秒大约有 2 次哈希溢出和每分钟 25 次排序溢出。

这种溢出频率是否可能是导致 tempdb 写入延迟高的罪魁祸首？

其他信息

我们按照每个内核数的建议为 tempdb 使用多个文件。tempdb 文件位于 RAID 1+0 SAN（具有高性能 SSD）上，但它与主数据库数据和日志文件位于同一设备上。tempdb 文件的大小足够大，它们很少增长。我们不使用跟踪标志 1117 或 1118。另一个变量是此设置为许多不同的数据库共享，这些数据库都经历中到高负载。

我们的 100 毫秒写入延迟远大于我们在 MSDN、SQL Skills 和其他站点上发现的 tempdb 写入延迟的可接受范围。但是，我们其他数据库的写入延迟很好（低于 10 毫秒）。根据其他统计数据，我们确实在大量使用 tempdb，尤其是对于内部对象。因此，我们正在深入研究以找出为什么我们的应用程序如此大量地使用内部对象。

我们的平台确实存在以不同方式表现出来的实际性能问题。我们一直在监控性能计数器、查看 DM 视图并分析我们的应用程序行为，以尝试深入了解我们系统的资源使用特征。我们现在专注于溢出，因为我们已经读到溢出具有巨大的负面影响，因为它们是在磁盘上而不是在内存中执行的。我们似乎有很多泄漏，但我想就人们认为的“高”获得一些意见。

Answer 1

这种溢出频率是否可能是导致 tempdb 写入延迟高的罪魁祸首？

是的，这是可能的，尽管通常是溢出的平均大小以及它们的深度（即递归散列溢出、多遍排序）比频率本身更重要。

SQL Server 提供了广泛的指标和 DMV 信息，以帮助您解决导致 tempdb 压力的各种因素，其中许多因素在 Microsoft 技术文章“在 SQL Server 2005 中使用 tempdb”（适用于 2005 以后的所有版本）中进行了讨论）。

您应该能够使用该文档中包含的指导和诊断查询来开始确定任何 tempdb 压力的主要原因。不要因为ALLOW_SNAPSHOT_ISOLATION未启用而忽略例如版本存储活动。除了快照隔离之外，许多功能还使用版本存储（例如触发器、MARS、RCSI）。

如果排序和散列溢出在高级别上确实很重要，您可能需要为此设置一些特定的监控。取决于您的 SQL Server 版本，这并不总是像人们希望的那样简单。要将排序和散列溢出与导致它们的特定查询连接起来，需要事件通知或扩展事件。SolidQ 文章“识别和解决排序警告”包含有关解决常见原因的详细信息和一些很好的一般建议。

您还应该与您的存储团队合作，确定有多少高延迟可归因于您的工作负载，有多少来自其他共享用途，以及有哪些重新配置选项。您对 SQL Server 指标的分析将有助于为这一讨论提供信息，SAN 人员能够提供的任何指标也将如此。