Sql server SQL Server 2008突然高IO暂停，查询陷入困境

SQL Server 2008企业版SP4 0.0.6547.0 x64 在Windows 2012R2上运行的补丁当前。 运行在Cisco UCM刀片服务器和6.0 Update 3 plus补丁上的虚拟机。 用于存储的灵活的CS700 SAN

这是一个带有12个vCPU的大型OLTP服务器。正常CPU使用率徘徊在6-11%左右

发生的情况是，在没有警告的情况下，IO暂停时间将超过上限（2000-1000毫秒），大多数查询将停止返回结果。Adam Machanic的sp_whoisactive将显示数十个活动查询。CPU在90%以上

SAN显示几乎没有活动，同一SAN上的所有其他虚拟机都以最佳方式运行

我们看到大量阻塞，因为停滞的进程持有阻塞，有些超时，并且在SPID上挂着阻塞。杀死相关的SPID可以暂时缓解压力，但几秒钟后，我们又回到了起点

唯一能减轻压力的是重新启动服务器

管理层要求找出一个真正的根本原因是正确的。去年夏天，当这种情况发生时，由于CEO级别的知名度，我们聘请了微软的支持人员，他们目瞪口呆，没有提供任何实际的根本原因

我不能做的是升级SQL server。如果我们实现任何较新的SQL Server版本，则机器承载一个打包的应用程序，而包发布者拒绝支持其软件。我非常想去2014/2016/2017年，我觉得这会解决这个问题和其他问题

无论如何，我搜索了bug报告，没有看到任何匹配的东西

有人碰到过这个问题吗？如果是，你找到了根本原因了吗？我有一种直觉，认为SQL 2008、Windows 2012R2或它们之间的交互方式都存在缺陷。但我不想在没有确凿证据的情况下把这些写进RCA

如果有任何建议，我将不胜感激。

这是我的方法

1.）尝试消除存储问题。我们曾经遇到存储问题（SAN），根本原因似乎是一些。您可以进一步检查您的存储是否在可接受的范围内运行

你应该从下面的计数器开始，看看它们是否小于15毫秒

Avg.Disk sec/Read—从磁盘读取数据的平均时间（秒）。
Avg.Disk sec/Write—是将数据写入磁盘的平均时间，以秒为单位

这里有更多信息：

2.）消除存储问题后，您可以进一步检查SQLSERVER是否是唯一导致IO峰值的应用程序，或者是否有任何其他应用程序导致IO峰值。您可以使用资源监视器查找此问题

3.）如果您已到达此处，SQLSERVER可能是罪魁祸首。请执行以下步骤，并尝试按照相同的顺序执行，然后查看每个步骤后问题是否仍然存在

请记住，高IO可能是由于

• 过时的统计数据和缺少的索引：您可能没有定期更新统计数据，或者某些类型的查询可能需要更频繁的索引重建/统计数据更新

• 收集导致高IO的查询并尝试对其进行调优，您可以观察已完成的读取数并尝试添加索引以最小化读取数

• 进一步检查内存压力，有时高内存使用率会导致缓冲池刷新，从而导致查询进入磁盘。您可以查找名为

  PLE

  的计数器，看看什么对您的环境有利

---

进一步的研究指向VMWare。机器分配了304GB的RAM，其中264GB分配给了SQL Server。但是，底层主机在RAM上的过度使用量很大。我们怀疑随着页面寿命的下降，以及其他虚拟机也需要真正的RAM，会出现颠簸
谢谢

---

约翰。
看来你走对了方向。您有一些查询相互阻塞和/或导致与您的SAN无关的高等待，或者从文章中听起来是这样。我个人会从和查询相关的开始。请确保没有两个资源密集型作业并行运行，如CHECKDB和REINDEX等。简单地重新启动SQL服务可能与服务器重新启动的操作相同，但这并不能解决出现问题时发现的核心问题，因为没有运行索引重新排序或重建。也没有运行任何checkDB或备份。由于重启了，我们不得不等待事件再次发生，以便使用sp_闪电战。。。工具集。谢谢你的帮助！你好PLE通常约为40-45分钟；它移动不多。IO速度不高。IO等待时间很长。我们已经分析了SAN流量，它是最小的。SQL本身发出的IO请求非常少，SAN正在快速为它们提供服务。统计数据和索引每晚重新组织/重建。长IO暂停—您提到的度量—仅在SQL Server端。SAN报告几乎没有流量。值是多少，您需要根据一些因素进行检查：我知道Jonathan的工作。PLE在40-45分钟范围内。用他的配方奶粉，我应该把5个半小时以下的任何东西都视为不良反应。为了到达那里，我需要1.3 TB的RAM。我需要澄清的是，当我们被这一问题困扰时，并没有特别的查询流量。这是毫无预兆的。你试过我概述的步骤了吗？是的！在我写第一张便条之前！