服务器级别重复出现的性能问题

Question

我的一台使用 SQL Server 2019 标准版的服务器面临奇怪的性能问题。

用户开始抱怨该应用程序非常慢/反应迟钝。为了检查发生了什么，我登录到 SQL（没有任何问题）并且在sp_whoisactive没有任何参数的情况下运行。它表明我的会话是唯一活跃的会话。所以，我运行sp_blitzfirst，也没有任何参数......花了 90 秒才完成。结果并不是很有趣。我有0优先级在 1 到 199 之间的警告。顶部等待指出，该脚本PAGEIOLATEH_SH显示了 84 秒的等待时间（顺便说一句，这很奇怪，因为我有 8 个核心，该脚本应该比较相隔 5 秒的快照，因此最大可能的等待时间时间应该是40秒，不是吗？）。

运行时，sp_blitzfirst我尝试检查是什么阻止了它sp_whoisactive，它还显示我的会话是唯一的会话，并且它显示在wait_info列 中(9ms)PAGEIOLATCH_SH:MMLIVE:1(*)。

我需要进行一些谷歌搜索/阅读来检查等待类型的含义，当我在大约 30 分钟后返回服务器时，问题就消失了（例如sp_blitzfirst在 6 秒内返回结果）。

这似乎不是一次性事件，因为有人告诉我，在我不在场的情况下，过去两周内至少发生了两次。

所以，我的理解是，性能问题是由缓慢的 SQL 服务器引起的（因为在报告它们时，即使我直接在服务器上运行的诊断查询也非常慢）。但与此同时，它不能是由直接在数据库上运行的任何进程引起的（因为我会看到该进程带有sp_whoisactive）....所以，它必须是虚拟机或硬件级别的。我对当时排名第一的等待类型的理解是，SQL 努力将数据从磁盘提取到内存。因此，我们通过系统管理员检查了虚拟机统计信息，但绝对没有任何异常情况。我们检查了共享相同存储的所有虚拟机的 IO 统计信息，但也有一些特殊情况（在报告问题期间）。

不幸的是，我没有对该服务器的第三方监控。

您能否告知它可能是什么或/以及我可以监视什么以在下次出现问题时捕获并确认根本原因？

Answer 1

PAGEIOLATCH_SH是与磁盘相关的等待类型，特别是等待从磁盘加载数据页。根据您描述的症状，SQL Server 实例中没有明显运行的内容，我同意这可能是硬件问题或您的服务器上运行的其他问题（在 SQL Server 实例之外）。

不久前，我的虚拟机中出现了一个磁盘损坏问题（来自 VMWare 的错误），通过查看 SQL Server 中的任何 I/O 统计信息很难检测到该问题。但最终帮助我确定问题的是使用CrystalDiskMark直接在服务器上对磁盘本身进行基准测试，从而将我的 SQL Server 实例排除在外。因此，每当我怀疑 SQL Server 实例之外的磁盘发生异常情况时，我都会首先想到这一点。

除此之外，我会检查是否有任何磁盘密集型操作也可以直接在服务器上进行，例如防病毒、服务器级备份/快照、Windows 任务计划程序作业等。

下次发生这种情况时，您还可以打开Windows 资源监视器，它将实时显示磁盘上哪些内容消耗最多的读写操作。

作为参考，这是我的冒险经历，CrystalDiskMark 帮助我解决了我的问题。聊天中的更多信息、建议和解决方案。

Answer 2

根据此 StackOverflow 问题的答案，在 SQL Server 上具有高效查询的最小负载期间，PAGEIOLATCH_SH 等待类型可能表明磁盘子系统或服务器上的其他进程（SQL Server 本身之外）竞争资源出现问题。那里有关于建议的故障排除方法的更多详细信息。

另请参阅已接受答案中引用的Microsoft 文档：

当任务正在等待 I/O 请求中的缓冲区的锁存器时发生。锁存请求处于共享模式。长时间等待可能表明磁盘子系统存在问题。