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