我有一个 SQL Server 实例（SQL Server 2008 R2、Windows 2008 R2），在非常短的随机时间段内（大约 15-20 秒）抱怨它的一些 I/O 请求花费的时间超过 15 秒。（“SQL Server 遇到 x 次 I/O 请求在文件 x 上的完成时间超过 15 秒”） 有问题的磁盘是 SAN 的一部分。通常，在这种情况下，通常会看到磁盘上的 IOPS 或吞吐量需求激增，从而产生延迟，并可能暗示 LUN 需要增强以满足服务器的需求。然而，在这种情况下，没有这种尖峰——相反，根据 perfmon，受影响磁盘上的活动从稳定状态变为几乎没有任何活动，并且延迟实际上得到了很大改善。（而且，我应该补充说，我们' 我在 SQL Server 端搜索了任何活动突然爆发的证据，但无济于事。工作负载的性质使得服务器活动不可能突然下降。）在缓慢的 I/O 事件之后有一个短暂的补偿性峰值，因为请求在中断后赶上。
SAN 人员仔细检查了所有内容（包括主机的配置），并声明从他们的角度来看没有任何问题。碰巧我们在这台服务器上同时使用了防病毒软件（具有适当的文件排除）和像文件系统驱动程序一样运行的加密解决方案，所以我很自然地怀疑这两者中的一个或两个可能是问题的根源. 但是当我把所有人都叫到客厅来揭露凶手时，我希望能够出示确凿的证据。除了咨询供应商（我们自然会这样做）之外，对于解决可能由应用程序拦截文件系统请求引起的间歇性延迟问题有什么建议吗？也许有任何工具或技术可以准确显示是什么在减慢速度？我' 恐怕关闭 AV 或加密看看会发生什么是行不通的。更复杂的是，到目前为止，这个问题无法按需重现。