我们的企业应用程序使用 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 视图并分析我们的应用程序行为，以尝试深入了解我们系统的资源使用特征。我们现在专注于溢出，因为我们已经读到溢出具有巨大的负面影响，因为它们是在磁盘上而不是在内存中执行的。我们似乎有很多泄漏，但我想就人们认为的“高”获得一些意见。