RAM 磁盘上的 SQL Server tempdb？

Question

我们的供应商应用程序数据库是 TempDB 密集型的。

该服务器是虚拟的 (VMWare)，具有 40 个内核和 768GB RAM，运行 SQL 2012 Enterprise SP3。

包括 TempDB 在内的所有数据库都位于 SAN 中的第 1 层 SSD 上。我们有 10 个 tempdb 数据文件，每个文件都预先增长到 1GB 并且它们永远不会自动增长。与 70GB 日志文件相同。跟踪标志 1117 和 1118 已经设置。

sys.dm_io_virtual_file_stats 显示过去一个月对 tempdb 数据和日志文件的读取/写入超过 50 TB，累计 io_stall 为 250 小时或 10 天。

在过去的 2 年中，我们已经调整了供应商的代码和 SP。

现在，我们正在考虑将 tempdb 文件放在 RAM 驱动器上，因为我们有大量内存。由于 tempdb 在服务器重新启动时被破坏/重新创建，因此它是放置在易失性内存中的理想候选者，该内存在服务器重新启动时也会被刷新。

我已经在较低的环境中对此进行了测试，它导致查询时间更快，但 CPU 使用率增加，因为 CPU 正在做更多的工作，而不是等待缓慢的 tempdb 驱动器。

有没有其他人将他们的 tempdb 放在高 oltp 生产系统的 RAM 上？有什么大的缺点吗？是否有任何供应商可以专门选择或避免？

Answer 1

首先，补丁：确保您使用的是 2012 Service Pack 1 Cumulative Update 10 或更新版本。在 SQL 2014 中，Microsoft 将 TempDB 更改为不那么急于写入磁盘，并且他们惊人地将其向后移植到 2012 SP1 CU10，这样可以减轻很多 T​​empDB 写入压力。

其次，获取延迟的确切数字。检查sys.dm_io_virtual_file_stats以查看 TempDB 文件的平均写入停顿。我最喜欢的方法是：

sp_BlitzFirst @ExpertMode = 1, @Seconds = 30 /* Checks for 30 seconds */
sp_BlitzFirst @SinceStartup = 1 /* Shows data since startup, but includes overnights */

查看文件统计部分，重点关注物理写入。自从Startup 数据可能有点误导，因为它也包括运行CHECKDB 的时间，这真的会影响您的TempDB。

如果您的平均写入延迟超过 3 毫秒，那么是的，您的 SAN 中可能有固态存储，但它仍然不快。

首先考虑 TempDB 的本地 SSD。良好的本地 SSD（例如英特尔的 PCIe NVMe 卡，价格低于 2000 美元，尤其是在您描述的尺寸下）具有极低的延迟，低于共享存储所能达到的延迟。但是，在虚拟化下，这会带来一个缺点：您无法将来宾从一台主机迁移到另一台主机以对负载或硬件问题做出反应。

最后考虑一个 RAM 驱动器。这种方法有两个大问题：

首先，如果您确实有大量的 TempDB 写入活动，那么内存的变化率可能会非常高，以至于您无法在没有所有人注意到的情况下将虚拟机从一台主机迁移到另一台主机。在 vMotion 期间，您必须将 RAM 的内容从一台主机复制到另一台主机。如果它的变化真的那么快，比您通过 vMotion 网络复制它的速度快，您可能会遇到问题（特别是如果此框涉及镜像、AG 或故障转移群集。）

其次，RAM 驱动器是软件。在我完成的负载测试中，在非常繁重的 TempDB 活动下，它们的速度并没有给我留下深刻的印象。如果它太重以至于企业级 SSD 无法跟上，那么您也会对 RAM 驱动器软件征税。在上线之前，您真的希望对其进行大量负载测试 - 尝试在不同索引上同时进行大量索引重建，所有这些都使用 sort-in-tempdb。