SQL Server发生I / O请求的时间超过15秒

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

将3台Dell PowerEdge R630服务器组合到可用性组中，所有3台都连接到单个RAID SAN存储单元，该存储单元是一个RAID阵列

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

SQL Server在数据库ID 8
的文件[F：\ Data \ MyDatabase.mdf]中遇到11次I / O请求，而这些请求花费的时间超过15秒。OS文件句柄为0x0000000000001FBC。
最新的长I / O的偏移量是：0x000004295d0000。
长I / O的持续时间为：37397毫秒。

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

解决与存储相关的特定问题的最常用方法或最佳做法是什么？必须使用哪些性能计数器，工具，监视器，应用程序等来缩小此类消息的根本原因？可能会有可以提供帮助的扩展事件，或者某种审计/日志记录？

我们有类似的设置，最近在日志中遇到了这些消息。我们正在使用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毫秒左右，这与应用程序中更好的性能相关。考虑到这些要点，希望您可以找到解决方案。

这很少是磁盘问题，而通常是网络问题。您知道吗，SAN中的N？

如果您去SAN团队开始谈论磁盘速度慢的问题，它们将为您显示一个延迟为0毫秒的精美图表，然后将订书机对准您。

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

然后，您可以使用Crystal Disk Mark或diskpd验证这些速度。如果他们没有排队，很可能就是网络。

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

作为DBA，您可以避免这些事情的一件事就是确保您的维护和其他繁重的数据任务（例如ETL）不会同时进行。这无疑会给存储网络带来很大压力。

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

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

为什么要在SAN上存储数据？重点是什么？所有数据库性能都与磁盘I / O关联，并且您正在使用3台服务器，它们后面只有一个设备用于I / O。那是没有道理的，不幸的是如此普遍。

我一生都在遇到设计不佳的硬件平台，而人们只是尝试设计大型计算机。这里的所有CPU功能，那里的所有磁盘...希望没有远程RAM之类的东西。最可悲的是，他们用比原本要贵十倍的大型服务器来弥补这种设计效率的不足。我看到40万美元的基础设施比一千美元的笔记本电脑慢。

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

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

您在评论中说，您正在考虑将SSD放入服务器中。与SAN相比，您将无法识别使用专用SSD的设置，即使在同一驱动器上使用数据和事务日志文件，也可以将其性能提高500倍。最先进的SQL Server将具有快速独立的SSD，用于在不同的硬件控制器通道上存储数据和事务日志（大多数服务器主板有多个）。但是与您当前的设置相比，我们在这里谈论的是科幻。只需尝试一下SSD。

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

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

在我们决定安装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毫秒

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

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

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

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

3）没有具体的时间安排

在显示“ SQL Server遇到事件...”的消息期间，
记录这些消息时没有维护或磁盘沉重的ETL运行

4）Windows事件查看器

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

5）开始检查前10个查询

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

6）我们没有SAN团队

我们只有1位sysadmin可以帮助您偶尔
访问SAN的网络路径-它是多路径的，3台服务器中的每台都有2条网络电缆，分别通向交换机和SAN，其速度为1 GB /秒

7）没有CrystalDiskMark结果

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

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

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

9）SQL Server错误日志

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

详细信息显示，检查点尝试刷新的数据量很小，并且需要很长时间才能完成，并且总体速度约为0.25 MB /秒...很奇怪

10）最后，此图显示了存储故障排除图表：

看来我们只是遇到了“硬件问题：与系统管理员/硬件供应商合作，以解决对SAN，旧/故障驱动程序，控制器，固件等的任何错误配置”。

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

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

解析度：

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

由于我们有可用性组，因此将数据库数据文件从SAN迁移到辅助副本上的SAN上，然后进行了故障转移，并在以前的主数据库上迁移了文件，从而使总停机时间最少-不到1分钟

现在，每个服务器都有数据库数据的本地副本，并且对上述SAN进行了完整/差异/日志备份
，而Windows Event Viewer日志中不再显示“ SQL Server遇到了发生...”消息，以及备份的性能，完整性检查，索引重建，查询等已大大增加

自从将DB文件迁移到SSD以来，在IO延迟方面提高了多少性能？

为了评估影响，迁移前2周和迁移后4周使用的性能Windows Performance Monitor记录：

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

摘要

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

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