我正在帮助对新 SQL Server 实例的硬件进行基准测试，操作系统中呈现的数据文件卷是从 Symmetrix SAN 上的一组主轴中分割出来的。该服务器尚未安装 SQL Server，因此机器上唯一的活动就是我们的基准测试。
现在，我们的存储工程师表示，该卷及其资源专用于我们的新服务器（我无法查看实际的 SAN 配置），但性能基准测试却令人担忧。例如，数字看起来不错，直到突然间，随机地，我们在 IO 基准测试工具中看到等待时间为 100 秒，而 perfmon 中的磁盘队列长度为 255。
此 SAN 具有 8 GB 缓存，此外，除了我们的应用程序之外，还有其他应用程序使用 SAN。我想知道（即使我们的卷的主轴应该专用于我们）缓存在性能测试期间是否可能受到重击，或者我们的卷所在的主轴可能并非真正专用于我们。
我们的存储工程师并没有给我们太多帮助来帮助我们追踪问题，所以如果有人有诊断此类问题的经验并愿意分享见解和故障排除方法，我将不胜感激。
答案1
@arcain
您使用什么基准测试工具？
市面上有许多工具，例如 SQLIOSim 和 SQLIO，根据它们的配置方式，可能会导致您的磁盘队列长度达到很高的水平，但这没关系，因为这是测试的一部分。问题在于您提到的等待时间，对我来说，这是磁盘争用的明显迹象。除了太多 VM 导致的 SAN 结构饱和之外，我的经验是磁盘（不是 SSD 时）始终是最大的瓶颈。话虽如此，除非与正在积极使用它们的另一台主机共享，否则它们通常不会导致等待状态。
在这些情况下，我建议使用 MS 的 SQLIO（如果您尚未使用的话）。由于您的 Symmetrix 有 8GB 缓存，我将使用 16GB 或更大的测试文件来测试缓存，以确保变化不是缓存本身，而是底层磁盘实际输出的内容。
您可以使用 SQLIO 创建用于一系列测试的文件，然后对其执行以下操作：
sqlio -kW -t2 -s120 -dE -o4 -fsequence -b64 -BH -LS Testfile.dat
-d 参数指的是驱动器号，在本例中为 E：
此测试在 2 分钟 (-s120) 内执行一组连续写入，您可以将其打包成一个带有时间戳的简单批处理文件，以帮助您跟踪一天中的时间并将结果传输到日志文件以供查看。编写批处理以在一段时间内重复执行上述操作或类似操作并查看结果。样本越大越好。
如果磁盘实际上是专用的，并且由于您正在通过缓存推送数据，则产生的 IO、MB 和延迟应该非常接近（1-5% 的变化）。如果超出该范围，达到 15% 或更高，则可能存在磁盘争用。
另外，一定要记下测试的日期和时间以及测试的驱动器。所有 SAN 都具有某种日志记录功能，用于分析以下内容：
- 快速写入 - 写入缓存，然后刷新到磁盘
- 延迟快速写入 - 写入的全局缓存已饱和，需要将一些先前的写入刷新到磁盘，以便为新传入的写入请求腾出空间的情况
- 读取命中 - 全局缓存满足的读取
- 读取未命中（长和短） - 读取要么部分满足全局缓存（短），要么根本不满足，必须从磁盘中提取所有内容（长）
您应该能够请求此信息来帮助评估您的 Symmterix 的性能，因为这是与其他主机共享的 SAN。
如果可以的话，请回复一些结果，我会非常乐意对它们进行审查。
答案2
缓存将由您和阵列上的其他服务器共享。主轴可能与其他服务器共享。只有您的存储管理员才能确切知道。
也可能是货架或后端环路已满（不太可能，但有可能）。
如果一切顺利，然后事情会变得一时糟糕，然后又恢复正常，听起来就像你正在填充阵列上的缓存，并且你开始直接写入磁盘，这是一个问题，因为磁盘已经以 100% 的速度运行。LUN 后面有多少个主轴？当一切正常时，你看到什么样的性能？