Con*_*lls 0 performance storage-area-network sql-server
我在连接到 IBM Shark 的刀片上使用 SQL Server 数据仓库解决方案时遇到了性能问题。由于页面闩锁等待时间过长，磁盘 I/O 性能似乎异常缓慢。其他从事基于 SQL Server 的 MIS 项目的人报告了类似的症状，但没有明显的解决方案。我尝试过的一些测试是：
在设置为 RAID-10 的 shevles 上构建部分或全部卷。这没有任何明显的影响。
禁用 SQL Server 上的强制直写行为（这可能是安慰剂 - 见下文）。
没有任何测试对速度产生显着影响，并且系统在具有直接连接的 SCSI 阵列的硬件和 O/S 规范（Windows 2003 服务器 EE）大致相似的机器上的基准测试速度大约是其两倍。在 SAN 上，我有三个卷，每个卷安装了 8 个磁盘（RAID-10 日志、RAID-10 tempdb、RAID-10 数据）。在带有直接附加磁盘的机器上，我有 6 个内部和 14 个外部 10k SCSI 磁盘。
请注意，Shark 有 32GB 的缓存 RAM，这应该足以适应测试的应用程序的工作集。
我调查的一个途径是用于 SAN 存储的 SQL Server 认证程序，其中 SAN 通过强制直写位集来尊重 I/O。我可以找到声称符合此规定的 EMC、HP 和 Hitachi SAN 的文档，但找不到关于 Shark 的此类文献。
有没有人在 Shark 上遇到过类似的性能问题——如果有的话，你对此有什么见解吗？
如果您在此处查看我的 SAN 性能测量说明：
http://sqlserverpedia.com/wiki/SAN_Performance_Tuning_with_SQLIO
将文本文件的结果发布在网络上的某个位置，并在您的问题中包含指向它的链接。这应该有助于我们弄清楚限速是多少。
另外，您如何在服务器和 SAN 之间进行连接？您使用了多少个 HBA，您使用的是哪种多路径软件？如果您只使用 2 个 HBA 或者您没有使用多路径软件，那么您将很快达到带宽限制。使用 Shark 之类的东西，您将需要使用至少 4 个 HBA 和良好的主动/主动多路径软件，以获得良好的吞吐量。