闪存上的慢检查点和 15 秒 I/O 警告

Question

过去几周，我们一直在努力找出导致这些 I/O 问题和检查点变慢的可能原因的根本原因。

乍一看，这显然是 I/O 子系统错误，应该归咎于 SAN 管理员。但最近我们将 SAN 更改为使用全闪存，但截至今天，错误仍然弹出，我不知道为什么，因为我运行的每个指标，无论是等待统计数据还是任何其他指标，都是为了检查 SQL 服务器是否可行罪魁祸首似乎恢复正常。

它并没有真正加起来。也很可能是其他东西正在咀嚼磁盘并且 SQL Server 在这里成为受害者......但我无法找出什么？

数据库位于可用性组中，当这些事件发生时，我们确实会看到角色更改和翻转以及超时发生。

任何帮助解决这个问题将不胜感激。如果需要任何进一步的细节，请告诉我。

错误消息。以下

SQL Server 在数据库 [ABC] (7) 中的文件 [E:\MSSQL\DATA\ABC.mdf] 上遇到了 14212 次 I/O 请求需要超过 15 秒才能完成。操作系统文件句柄是 0x0000000000000D64。最新的long I/O的偏移量为：0x0000641262c000

SQL Server 在数据库 [XYZ] (7) 中的文件 [E:\MSSQL\DATA\XYZ.mdf] 上遇到了 5347 次 I/O 请求需要超过 15 秒才能完成。操作系统文件句柄是 0x0000000000000D64。最新的long I/O的偏移量为：0x0000506c060000

FlushCache：在 925084 毫秒内清理了 111476 个 buf，其中 62224 次写入（避免了 19 个新的脏 buf），用于 db 7:0 平均吞吐量：0.94 MB/秒，I/O 饱和度：55144，上下文切换 98407 最后一个未完成的目标：101241077 次写入FlushCache：在 248687 毫秒内清理了 5616 个 buf，其中 3126 个写入（避免了 3626 个新的脏 buf），用于 db 6:0 平均吞吐量：0.18 MB/秒，I/O 饱和度：10080，上下文切换 20913 次未完成的目标：2，平均写入延迟

以下是 30 分钟内的虚拟文件统计信息：

还有等待统计：

这是系统架构师的注释：

我们将高 I/O 密集型工作负载（例如 DB）的工作负载分开，因此我们每个主机只有一个。当前主机的规格是 Dell R730，具有 16 核 Xeon E5-2620（2 个插槽）、512GB 和用于存储的 2x10G 互连。集群上的其他 VM 或主机都没有遇到这些问题。VM 和工作负载的存储位于 Pure FA-x20 上。

一般系统信息：

• SQL Server 2012 sp3-cu9（企业版）
• 总内存：128 GB
• 总数据库大小：接近 1 TB

Answer 1

过去几周，我们一直在努力找出导致这些 I/O 问题和检查点变慢的可能原因的根本原因。

听起来不错。你收集并分解了微过滤器和存储跟踪吗？如果是这样，它显示了什么？

乍一看，这显然是 I/O 子系统错误，应该归咎于 SAN 管理员。但最近我们将 SAN 更改为使用全闪存，但截至今天，错误仍然弹出，我不知道为什么，因为我运行的每个指标，无论是等待统计数据还是任何其他指标，都是为了检查 SQL 服务器是否可行罪魁祸首似乎恢复正常。

我想在这里讨论两个不同的领域。

第一个是 SQL Server 本身实际上并不对 I/O 做任何事情，它使用典型的 Windows API 将其发布到 Windows。无论是 ReadFile、WriteFile 还是它们的向量化 I/O，都取决于 Windows。SQL Server 保留挂起 I/O 的列表，并在不同时间检查该 I/O 以获取未完成的状态。这也是使用典型的 Windows 异步 I/O 模型完成的。当我们使用 GetOverlappedResult Windows API 检查状态时，根据Windows超过 15 秒，当 I/O 已挂起且未完成时，将打印该消息。这意味着，SQL Server 在这件事上并没有真正的发言权，它是通过 Windows 返回的。

第二项是，仅仅因为它是全闪存和 10 Gb 光纤并不意味着某些东西没有设置或配置不正确，驱动程序、过滤器或其他错误或项目没有受到影响，或者某些东西不是物理上的错误的。只是为了得到一个想法：

1. 视窗配置
2. Windows 驱动程序，例如正在设置的多路径和最新版本
3. 过滤驱动程序（您知道，磁盘设备、防病毒软件、备份等）
4. 管理程序（如果有）
5. HBA 驱动程序
6. HBA 固件
7. HBA 配置
8. 物理布线
9. 光纤交换
10. I/O 组连接/SAN/设备
11. SAN/设备的配置

这一切都在 SQL Server 下，只是 SQL Server告诉您有关它的信息。

数据库位于可用性组中，当这些事件发生时，我们确实会看到角色更改和翻转以及超时发生。

这是非常好的信息，尽管这并不一定意味着它完全相关。现在，如果它只在发生故障转移时发生，那么这个问题会更加磨练，这对我来说听起来更像是驱动程序等。不喜欢向其抛出大量混合 I/O，因为故障转移通常会导致重做/撤消和重新同步的发生，这可能会导致未完成的 I/O 激增。

任何帮助解决这个问题将不胜感激。

除非它是一个查询或一组查询正在推动高 IOP，这听起来不像，因为 30 分钟的快照只有 737,465 个 I/O 操作，平均为 410 个 IOP（不是那么高，特别是如果它是闪存) 查看 SQL Server 内部不会帮助解决这个问题，因为 SQL Server 是信使。

如果还没有，你想收集：

1. 花费的微过滤时间。如果您没有其他任何东西，这可以通过 WPR (XPerf) 完成。如果 I/O 在过滤器驱动程序中停滞，这会有所帮助。
2. 斯托波特跟踪。这将是我们途中的最后一站，也是返程的第一站。这两个读数之间的任何时间都是在 Windows 之外花费的时间......它还会向您显示目标以及另一端的缓慢位置（但并不总是决定性的）。

如果这些都无助于诊断或缩小问题范围，那么可能是时候通过 Windows 存储支持打开一个票证并收集所有数据，以便大家可以在同一页面上开始。

Answer 2

您提到您正在检查等待统计数据和“所有其他指标”。我假设你看到高PAGELATCH和WRITELOG等待？只是为了仔细检查，你有没有审查sys.dm_io_virtual_file_stats？这就是我在获取这些 15 秒 I/O 消息时开始的地方。

使用 Erin Stellato 的优秀文章“虚拟 Filestats 做什么，不做什么，告诉您 I/O 延迟”作为使用查询的指南。每 5 或 15 分钟将该 DMV 的快照记录到表中。寻找平均停顿/延迟的峰值。

查看在这些峰值期间读取/写入的数量或每次读取/写入的平均字节数是否增加。可能是您的维护或用户查询使 I/O 子系统的流量超出其处理能力。这些查询需要调整，或者维护任务需要分解或移动到一天中的不同时间。

与您的 SAN 管理员合作，查看 SAN 中是否存在与这些时间相关的任何“嘈杂邻居”或错误。将 SAN 设置与其他 SQL Server 设备进行比较 - 您可能在物理连接级别存在吞吐量问题，或者您有需要调整的缓存设置，或者需要安装更新等。

我意识到这些步骤有些笼统，但希望它能为您提供下一步的方向。

关于这一点：

我们将高 I/O 密集型工作负载（例如 DB）的工作负载分开，以便我们每个主机只有一个...集群上的其他虚拟机和主机都没有遇到这些问题

我认为 SQL Server 将是唯一一个看到这些问题的人，如果它是唯一一个在主机上具有高 I/O 工作负载的人 - 其他服务器/应用程序甚至可能不会注意到或有任何报告方式正在经历磁盘延迟。

在您的虚拟文件统计屏幕截图中，E 驱动器看起来特别有问题。那个驱动有什么不同吗？

...用于存储的 2x10G 互连

你可能有布线问题。考虑重新安装它们/确保它们有牢固的连接。可能换用不同的、已知良好的电缆。如上所述，让 SAN 团队检查缓存设置和其他配置，以查看此卷/主机与其他 SQL Server VM 是否存在任何差异。