排除可能由文件系统驱动程序引起的I / O延迟

我有一个SQL Server实例（SQL Server 2008 R2，Windows 2008 R2），它非常短的随机时间约15-20秒，它的一些I / O请求花费的时间超过了15秒。 （“SQL Server在x文件上遇到x个需要15秒以上才能完成的I / O请求”）所涉及的磁盘是SAN的一部分。 通常，在这种情况下，通常会看到磁盘峰值上的IOPS或吞吐量需求，从而产生延迟，并build议可能需要加强LUN来满足服务器的需求。 然而，在这种情况下，没有这样的高峰 – 相反，根据perfmon，在受影响的磁盘上的活动从稳定状态变为几乎没有任何活动，而延迟实际上提高了很多。 （而且，我还要补充一点，我们已经在SQL Server端search了任何突然爆发的活动的证据，但没有成功，工作负载的性质使得服务器活动的突然下降是不可能的。缓慢的I / O事件之后的一个短暂的补偿性峰值，因为请求在中断之后赶上。

SAN人们用一把精细的梳子（包括主机的configuration）把所有东西都完成了，并且从他们的angular度宣称没有任何问题。 恰巧我们在这个服务器上使用了反病毒（有适当的文件排除）和一个像文件系统驱动程序一样运行的encryption解决scheme，所以我自然而然的怀疑这两者中的任何一个或两个可能是问题的根源。 但是，当我打电话给大家进入客厅时，我想能够拿出一把吸烟枪来揭露凶手。 除了咨询供应商（我们当然这么做）之外，还有什么build议可以解决间歇性延迟问题，这些问题可能是由应用程序拦截文件系统请求引起的？ 任何工具或技术，也许，可能显示什么东西放慢速度？ 恐怕closuresAV或encryption看看会发生什么是一个非起动器。 只是使事情复杂化，到目前为止，这个问题不能在需要时复制。