SQL Server 遇到 I/O 请求耗时超过 15 秒的情况

Question

在生产 SQL Server 上，我们有以下配置：

3 台 Dell PowerEdge R630 服务器，合并到可用性组中
所有 3 台都连接到作为 RAID 阵列的单个戴尔 SAN 存储单元

有时，在 PRIMARY 上，我们会看到类似于以下内容的消息：

SQL Server 在数据库 ID 8 中
的文件 [F:\Data\MyDatabase.mdf] 上遇到了 11 次 I/O 请求需要超过 15 秒才能完成。操作系统文件句柄为 0x0000000000001FBC。
最近一次 long I/O 的偏移量为：0x000004295d0000。
长 I/O 的持续时间为：37397 毫秒。

我们是性能故障排除的新手

解决此与存储相关的特定问题的最常见方法或最佳实践是什么？

必须使用哪些性能计数器、工具、监视器、应用程序等来缩小此类消息的根本原因？

可能有一个扩展事件可以提供帮助，或者某种审计/日志记录？

更新：添加了我自己的答案（见下文），解释了我们为解决问题所做的工作

Answer 1

这不是磁盘问题，而是网络问题。你知道，SAN 中的 N 吗？

如果你去你的 SAN 团队并开始谈论磁盘很慢，他们会向你展示一个延迟为 0 毫秒的精美图表，然后将订书机指向你。

相反，向他们询问到 SAN 的网络路径。获取速度，如果它是多路径的，等等。从他们那里获取有关您应该看到的速度的数字。询问他们是否有设置服务器时的基准。

然后您可以使用Crystal Disk Mark或diskpd来验证这些速度。如果他们不排队，那么很可能是网络问题。

您还应该在错误日志中搜索包含“FlushCache”和“saturation”的消息，因为这些也可能是网络争用的迹象。

作为 DBA，您可以做的一件事是确保您的维护和任何其他数据密集型任务（如 ETL）不会同时进行。这肯定会给存储网络带来很大压力。

您可能还想查看此处的答案以获取更多建议：闪存上的慢检查点和 15 秒 I/O 警告

我在博客上写了一个类似的主题：从服务器到 SAN

Answer 2

我们有一个类似的设置，最近在日志中遇到了这些消息。我们使用的是 DELL Compellent SAN。以下是在收到这些帮助我们找到解决方案的消息时需要检查的一些事项

• 查看警告消息指向的磁盘的 Windows 性能计数器，特别是：
  • 磁盘平均 阅读时间
  • 磁盘平均 写时间
  • 磁盘读取字节数/秒
  • 磁盘写入字节/秒
  • 磁盘传输/秒
  • 平均 磁盘队列长度
• 以上是平均值。如果您在一个驱动器上有许多数据库文件，这些平均值可能会扭曲结果并掩盖特定数据库文件的瓶颈。查看Paul S. Randal 的这个查询，它返回 dmv 中每个文件的平均延迟sys.dm_io_virtual_file_stats。在我们的例子中，报告的平均延迟是可以接受的，但在幕后我们有许多文件的平均延迟 > 200 毫秒。
• 检查时间。有什么模式吗？它是否在夜间的某个时间更频繁地发生？如果是这样，请检查当时是否正在运行任何维护作业或任何可能增加磁盘活动并暴露 IO 子系统瓶颈的计划活动。
• 检查 Windows 事件查看器是否有错误。如果您的交换机或 SAN 过载或未为您的应用程序正确设置，您可能会在此日志中找到一些消息，最好将此信息提供给 SAN 管理员。在我们的案例中，我们一整天都经常收到 iSCSI 连接错误，暗示了问题所在。
• 查看您的 SQL Server 代码。当您收到这些消息时，您不应立即认为这是 IO 子系统问题并将其传递给您的 SAN 管理员。您需要尽自己的一份力量并查看数据库。您是否有经常在大量数据中运行的非常糟糕的查询？索引不好？事务日志写入过多？您可以使用一些开源查询对数据库进行健康检查，检查查询计划外观的示例是sp_blitzCache
• 不要忽视这些。今天，您可能每天收到它们几次……然后几个月后，当您的工作量增加而您忘记监控它们时，它们开始增加。收到大量这些消息会阻止 SQL Server 访问某个文件，如果它是tempdb，那就不好了。在我们的例子中，它变得非常糟糕，以至于 SQL Server 自行关闭。

我们的解决方案是将我们的交换机升级为 SAN 交换机。是的，这些都是 SQL Server 中要涵盖的要点。导致我们发现问题的原因是我们每天在 SQL Server 上的 Windows 应用程序事件查看器中收到大约 1500 个 iSCSI pdu 断开连接错误。这促使我们的 SAN 管理员对交换机进行调查。

升级后，iSCSI 错误立即消失，所有文件的平均延迟下降到 50 毫秒左右，这与应用程序的更好性能相关。考虑到这些要点，希望您能找到解决方案。

Answer 3

为什么将数据存储在 SAN 上？重点是什么？所有数据库性能都与磁盘 I/O 相关联，并且您使用 3 个服务器，它们后面只有一个用于 I/O 的设备。这毫无意义……不幸的是，这很常见。

SQL 服务器软件是一种非常先进的软件，它旨在利用任何硬件、CPU 内核、CPU 缓存、TLB、RAM、磁盘控制器、硬盘驱动器缓存......它们几乎包括所有文件系统逻辑。它们是在普通计算机上开发的，并在高端系统上进行基准测试。因此，SQL 服务器必须有自己的磁盘。将它们安装在 SAN 上就像“模拟”一台计算机，您将失去所有性能优化。SAN 用于存储备份、不可变文件和您刚刚将数据附加到的文件（日志）。

数据中心管理员倾向于将他们所能做的一切都放在 SAN 上，因为这样他们只需管理一个存储池，这比管理每台服务器上的存储更容易。这是一个“我不想做我的工作”的选择，而且是一个非常糟糕的选择，因为这样他们就必须处理性能问题，而整个公司都因此而受苦。只需在其设计的硬件上安装软件。把事情简单化。注意 I/O 带宽、缓存和上下文切换开销、资源抖动（在共享资源时发生）。您最终将维持 1/10 的设备以获得相同的原始输出功率，为您的运营团队省去很多麻烦，获得性能，让您的最终用户感到满意和更高效，让您的公司成为更好的工作场所，以及节省大量能源（地球会感谢你）。

您在评论中说，您正在考虑将SSD放入您的服务器中。您将无法识别使用专用 SSD 的设置，与 SAN 相比，即使数据和事务日志文件位于同一驱动器上，您也会获得大约 500 倍的改进。最先进的 SQL Server 将在不同的硬件控制器通道上为数据和事务日志提供快速独立的 SSD（大多数服务器主板有几个）。但与你目前的设置相比，我们在那里谈论科幻。试试SSD吧。

我一生都在遇到设计糟糕的硬件平台，人们只是在那里尝试设计大型计算机。这里所有的 CPU 能力，那里的所有磁盘......希望没有远程 RAM 这样的东西。最可悲的是，他们用比应有的成本高出十倍的大型服务器来弥补这种设计效率的不足。我看到 40 万美元的红外线比一台 1000 美元的笔记本电脑慢。

Answer 4

好的，对于任何有兴趣的人，

几个月前我们解决了问题中的问题，只需将直接连接的 SSD 驱动器安装到 3 个服务器中的每一个，并将数据库数据和日志文件从 SAN 移动到这些 SSD 驱动器

在我们决定安装 SSD 驱动器之前，这里总结了我对这个问题所做的研究（使用所有帖子的建议）：

1) 开始在所有 3 个服务器上收集以下驱动器的 PerfMon 计数器：

Disk F:是基于 SAN 的逻辑磁盘，包含 MDF 数据文件
Disk I:是基于 SAN 的逻辑磁盘，包含 LDF 日志文件
Disk T:直接附加 SSD，专用于 tempDB

下图是 2 周期间收集的平均值

Disk I: (LDF)有这么小的 IO 和延迟非常低，所以磁盘 I：可以忽略
你可以看到Disk T: (TempDB)与 相比有更大的 IO Disk F: (MDF)，同时它有更好的延迟 - 0 ms

显然磁盘 F 有问题：数据文件所在的位置，尽管 IO 低，但它具有高延迟和平均磁盘写入队列

2) 使用来自本网站的查询检查单个数据库的延迟

https://www.brentozar.com/blitz/slow-storage-reads-writes/

主服务器上的活动数据库很少有 150-250 毫秒的读取延迟和 150-450 毫秒的写入延迟
有趣的是，master 和 msdb 数据库文件的读取延迟高达 90 毫秒，考虑到它们的数据量小和 IO 低，这是可疑的 -另一个迹象表明 SAN 有问题

3）没有具体的时间

在此期间，“SQL Server 遇到了发生的事情...”消息出现
记录这些消息时没有运行维护或磁盘繁重的 ETL

4) Windows 事件查看器

没有显示任何其他提示问题的条目，除了“SQL Server 遇到了发生...”

5) 开始检查前 10 个查询

来自 sp_BlitzCache（cpu、读取等），并在可能的情况下进行优化
没有超 IO 重查询会搅动大量数据并严重影响存储，尽管
数据库中的索引是可以的，但我维护它

6) 我们没有 SAN 团队

我们只有 1 个系统管理员帮助处理
SAN 的网络路径 - 它是多路径的，3 个服务器中的每一个都有 2 根网络电缆连接到交换机，然后连接到 SAN，它应该是 1 GB/秒

7) 没有 CrystalDiskMark 结果

或者任何其他基准测试结果来自服务器设置时，所以我不知道速度应该是多少，并且此时无法进行基准测试以查看当前速度是多少，因为它会影响生产

8) 在相关数据库的检查点事件上设置扩展事件会话

XE 会话帮助发现在“SQL Server 遇到了发生...”消息期间，检查点发生的速度非常慢（最多 90 秒）

9) SQL Server 错误日志

包含“FlushCache”“饱和度”条目
这些应该在给定数据库的检查点时间超过恢复间隔设置时显示

细节显示checkpoint尝试刷新的数据量很小，需要很长时间才能完成，整体速度约为0.25 MB /秒......奇怪

10) 最后，这张图为存储故障排除图：

看来我们只是有一个“硬件问题：- 与系统管理员/硬件供应商合作修复 SAN、旧/有故障的驱动程序、控制器、固件等的任何错误配置”。

在另一个问题“慢检查点...”慢检查点和闪存上的 15 秒 I/O 警告 Sean 有一个非常好的列表，列出了必须在硬件和软件级别检查哪些项目以进行故障排除

我们的系统管理员无法检查列表中的所有内容，因此我们只是选择在此问题上投入一些硬件 - 根本不贵

解析度：

我们订购了 1 TB SSD 驱动器并直接安装到服务器中

由于我们有可用性组，将数据库数据文件从 SAN 迁移到次要副本上的 SSD，然后进行故障转移，并迁移前主服务器上的文件这允许最小的总停机时间 - 不到 1 分钟

现在每个服务器都有 DB 数据的本地副本，并且对提到的 SAN 进行了完整/差异/日志备份
。Windows 事件查看器日志中不再有“SQL Server 遇到了...”消息，以及备份的性能、完整性检查、索引重建、查询等显着增加

自从我们将 DB 文件迁移到 SSD 后，IO 延迟方面的性能提高了多少？

为了评估影响，使用了迁移前 2 周和迁移后 4 周的性能 Windows 性能监视器日志：

下面也是数据库级延迟统计比较（使用 SQL Server 在迁移前后捕获的虚拟文件统计数据）

概括

从 SAN 迁移到直接连接的本地 SSD 是非常值得的 它对
存储的延迟产生了很大影响，平均改善了 90% 以上（尤其是 WRITE 操作），我们不再有 20-50 秒的 IO 峰值

迁移到本地 SSD 不仅解决了存储性能问题，还解决了我担心的数据安全问题（如果 SAN 出现故障，所有 3 个服务器都会同时丢失数据）