我有一个在 Windows VMWare 平台上运行 SQL Server 的环境，使用在 RAID 6 中设置了 SSD 的 SAN，并使用 Veeam 进行服务器备份，使用 LiteSpeed 进行 SQL Server 备份。
在过去的一年中，我遇到过几次这样的问题：有时数据库的运行速度会变得非常慢，我的平均磁盘队列长度很高，但我的磁盘字节数/秒却远低于应有的水平。
这是数据库服务器上的性能监视器。当发生此问题时，平均磁盘队列长度始终在几百的范围内，磁盘字节数/秒保持在 5-15 MB/秒左右。在正常运行期间（当此问题未发生时），磁盘字节数/秒最高可达 900 MB/秒左右。
自从出现此问题以来，我已经更换了 SAN 硬件——包括交换机。但新硬件上的问题仍然存在。
我的理论是这不是 SQL Server 的问题，因为如果问题在于 SQL Server 使磁盘 I/O 饱和，我应该看到更高的磁盘字节数/秒。但每当发生此问题时，磁盘字节数/秒总是很低。
我认为可能是备份软件 - 要么运行在数据库服务器上，要么运行在使用相同 VMWare/SAN 的另一台服务器上 - 但在发生此问题时，服务器备份和 SQL Server 备份似乎都没有运行。
我最后的想法是这是 VMWare 的问题，但我已经联系他们，到目前为止他们还没有能够提供帮助。
重新启动数据库服务器可以解决问题。有时问题会在一天内再次发生，有时问题几个月都不会再次发生。每当问题发生时，我都不知道数据库上运行的正常工作负载之外还有什么问题。
导致磁盘吞吐量下降到应有水平的 1％ 左右的问题的原因是什么？
答案1
HDD 的工作队列越长，速度就越慢，反之亦然 - 您能向其投入的 IOPS 数量非常有限（大约 40-200，取决于等级和 RPM）。超过该点的任何需求增加都会进一步降低其性能。
创建 HDD 阵列会增加整个阵列中可能的读取 IOPS 总数，但通常小于简单地将其各个 IOPS 相加。写入 IOPS 更为复杂，并且在很大程度上取决于 RAID 级别、缓存等。
除此之外的任何事情都需要 SSD 和适当的控制器。
答案2
由于您已经在使用 SSD，我认为问题可能与我遇到的问题类似，TRIM 在 SSD 中无法正确处理。擦除 SSD 上的数据块不是即时的，准备一个块以供重复使用可能是一个缓慢的过程，并且可能是导致速度变慢的原因 - 如果您的可用块和准备好的块已耗尽，则在准备新块时阵列可能会急剧变慢。检查您的 SAN 是否知道这些是 SSD，并且它们已启用后台 TRIM。