我的一台使用 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 统计信息，但也有一些特殊情况（在报告问题期间）。
不幸的是，我没有对该服务器的第三方监控。
您能否告知它可能是什么或/以及我可以监视什么以在下次出现问题时捕获并确认根本原因？