SSD 上的 SQL Server tempdb 显示 IO

G D*_*ine 8 sql-server sql-server-2012 tempdb

我们最近将我们的 tempdb 文件分离到一个新的 SSD 并开始看到:

在文件 [T:\tempdb\tempdb4.ndf] 上发生了 5348 次 I/O 请求需要超过 15 秒才能完成。

我们多次出现此错误。当 tempdb 回到其原始 RAID 5 主目录时,我们没有看到错误。我遵循了 SQLIO 教程,我认为 SSD 在进行 8kb 随机读/写时应该比以前的 RAID 5 磁盘快得多。那么为什么我们会看到这些错误呢?

此外,为了证明并非一切都很好,我们通宵运行的批处理文件(发生这些错误的时间)需要 7 个小时。在旧磁盘上花费了 6.25 小时。

磁盘位于直接连接的阵列中。用于数据的 RAID5、用于日志的 RAID 10 和我们用于 SSD 的备用插槽。RAID 5 和 SSD 被格式化为 64kb 块大小。日志被错误地设置为 4KB 块大小(我知道 - 有机会时会修复)。

这些是 SQLIO 的结果:

T盘(ssd)
Ios=8KB随机写入,IOs/sec=31847.48,MBs/sec=248.8
Ios=8KB随机读取,IOs/sec=76391.66,MBs/sec=596.8

S盘(RAID 5)
Ios= 8KB随机写入,IOs/sec=2601.3,MBs/sec=20.32
Ios= 8KB随机读取,IOs/sec=3138.45,MBs/sec=24.51

对于 64K 顺序读/写,它们大致相同。

Tempdb 被拆分为 4 个 1.5Gb 文件(移动前后相同)。

SQL Server 2012 已修补到 SP3。

您知道是什么原因导致 SQL Server 报告所有这些 I/O 错误吗?

是否可能是阵列或 HBA 驱动程序问题?添加到直接连接阵列上的备用插槽中的单个磁盘是否需要在缓存方面进行仔细配置?

Jos*_*ell 7

我强烈建议您使用 Crystal Disk Mark 测试您的新 T:\ 驱动器。在此处查看 Brent Ozar 的指南:

如何使用 CrystalDiskMark 测试您的存储

将 T:\ 驱动器的结果与

  • 旧的 RAID 5 磁盘(以前是 tempdb)
  • 你的机器

如果 SSD 比其他两个设备慢,并且您的设置中没有其他任何变化*,则可能是磁盘本身、正在使用的驱动程序或该磁盘所在阵列的控制器存在问题,等等。

*自从您移动 tempdb 后可能发生的变化:

  • 数据库的 tempdb 文件的数量增加或减少(有人说“嘿,为什么不,因为我们必须重新启动数据库才能移动 tempdb”)
  • 重新安排维护任务以配合现在缓慢的夜间工作(尤其是那些有可能严重影响 tempdb 的工作,例如索引重建或 checkdb)
  • 移动 tempdb 的维护窗口也用于部署新代码(可能用于夜间工作),这些代码大量使用临时表,或者查询有严重溢出等

下一步

由于磁盘似乎相当快(根据您共享的基准),我认为记录sys.dm_io_virtual_file_stats您提到的夜间批处理作业前后的内容是个好主意。这将告诉您在该过程中 tempdb 上发生了多少 I/O。这很重要,因为可能真的有比磁盘可以处理的更多的 I/O。所以这就是你要做的:

  1. 在计划运行夜间批处理作业之前运行此查询:

    select * 
    from sys.dm_io_virtual_file_stats((select DB_ID('tempdb')), default);
    
    Run Code Online (Sandbox Code Playgroud)
  2. 将结果保存在某处(如 Excel 或其他东西 - 可能不在 tempdb 中:P)

  3. 等待 7 小时(直到作业完成)
  4. 运行相同的查询并保存结果
  5. 编辑您的问题以包含结果

然后我们可以获取两个快照的差异并确定在作业期间读取/写入了多少字节。您还可以使用这些数字来计算该期间的总体延迟。

注意:更细粒度的方法是每 5 分钟(如果需要,也可以更少)将该查询的结果记录到表中