我正在帮助为新SQL Server实例的硬件进行基准testing，并且数据文件提供给操作系统的卷是从Symmetrix SAN上的一组主轴刻出的。 服务器尚未安装SQL Server，因此该框中唯一的活动就是我们的基准testing。
现在，我们的存储工程师说这个卷和它的资源专用于我们的新服务器（我没有看到实际的SANconfiguration），但性能基准是令人不安的。 例如，数字看起来很好，直到突然，随机，我们看到我们的IO基准testing工具的等待时间为100秒，而在perfmon中的磁盘队列长度为255。
这个SAN有一个8 GB的caching，再加上除了我们的其他应用程序，使用SAN。 我想知道是否（尽pipe我们的卷的主轴应该是专门给我们的），在性能testing期间，caching可能会受到打击，或者我们的卷上的主轴可能并不是真的奉献给我们。
我们没有从我们的存储工程师那里获得很多帮助我们追踪问题的牵引力，所以如果任何人有诊断这样的问题的经验，并希望分享见解和故障排除方法，我会很感激。
@arcain
你使用什么基准工具？
SQLIOSim和SQLIO等许多工具（取决于它们的configuration方式）可能会导致磁盘队列长度达到较高的水平，但这也可以，因为它是testing的一部分。 问题是你提到的等待时间，对我来说，这是一个死硬盘的争夺。 除了由于虚拟机数量太多而导致的SAN结构饱和之外，我的经验是磁盘（当不是SSD的时候）永远是最大的瓶颈。 如前所述，除非与另一个积极使用它们的主机共享，否则它们通常不会导致等待状态。
在这种情况下，我build议使用MSIO的SQLIO（即如果这不是你已经使用的）。 由于您的Symmetrix具有8GBcaching，因此我将使用16GB或更大的testing文件进行testing，以便通过caching来确保变化不是caching，而是底层磁盘实际上正在展示的内容。
您可以使用SQLIO为一系列testing创build文件，然后对其执行以下操作：
sqlio -kW -t2 -s120 -dE -o4 -fsequential -b64 -BH -LS Testfile.dat
-d参数指的是盘符，在这种情况下是E：
该testing在2分钟（-s120）的时间段内执行一系列顺序写入操作，您可以用简单的batch file打包时间戳，以帮助您跟踪一天中的时间，并将结果传送到日志文件以供审阅。 编写批处理以执行上面的操作或类似的操作一段时间，然后查看结果。 样本越大越好。
如果这些磁盘实际上是专用的，并且由于您正在通过caching，所产生的IO，MB和延迟应该非常接近（1-5％的变化）。 如果超过15％或更高，那么你可能会有磁盘争用。
另一件事，一定要记下你的testingdate和时间，并针对你testing的驱动器。 所有的SAN都有一些logging来分析以下内容：
您应该能够请求这些信息来帮助您衡量Symmterix的性能，因为这是与其他主机共享的SAN。
如果可以的话，发回一些结果，我会更乐意回顾。
caching将在您和arrays上的其他服务器之间共享。 主轴可能与别的东西共享。 只有你的存储pipe理员肯定会知道。
这也可能是架子或后端环路容量（不太可能，但可能）。
如果一切都开始了，那么事情就会变成废话，然后回到正常状态，这听起来就像是填满了arrays上的caching，并且你开始直接写入磁盘，这是一个问题，因为磁盘是已经在100％运行。 LUN后面有多less个主轴？ 当事情工作正常时，你看到了什么样的performance？