我遇到了调整SAN的问题性能。 我正在使用带有SQLIO的EMC DMXtesting24个安装点，这些安装点是RAID-5。 我正在testing的主机有256GB的RAM和32个内核。
我在我的命令行中使用Param文件，如下所示：
M:\ASRS\ASRS_SQLData01A\testfile.dat 8 0x0 6000 M:\ASRS\ASRS_SQLData02\testfile.dat 8 0x0 6000 M:\ASRS\ASRS_SQLData03\testfile.dat 8 0x0 6000 示例命令行如下所示：
call sqlio -kR -s60 -fsequential -o8 -b64 -LS -Fparam.txt
我的问题是这样的：
当我testing1个挂载点时，我看到850MB /秒和14k IOs /秒，但是当我testing多个文件时，850MB /秒是我见过的最多的。 所以我相信我在某个地方遇到了一个瓶颈。 主机有8个4千兆光纤通道卡，所以我很难相信这是因为我猜测它是HBA / SP或SQLIO。
有什么我失踪，可能是瓶颈？ 这是正常行为，还是SQLIO应该聚合所有安装点的吞吐量？
作为一个侧面说明，为了certificateSQLIO不是问题所在，也不是“平均”跨文件的带宽，我在不同的挂载点上同时运行了2个SQLIO实例，并且看到大约400mb / s在各个。 对我来说certificate它不是SQLIO。
PowerPath（或系统中的等效设置）是否设置为正确地对HBA进行负载平衡？ 所有的HBA都能正常工作吗？ 您应该能够popup到服务器上，并查看Powerpathconfiguration以获得这些答案。
在Windows事件日志中查看是否有消息从HBA或powerpathpopup是非常值得的。
我不记得DMX是否使用存储池，但是在考察SAN性能时，一些很好的基本问题是：存储扩展了多less个磁盘？ 更多通常是更好的。 如果只是几个磁盘，请提问。 只要您询问磁盘，您也可以询问RPM的价格。 如果你不能获得SSD，那么速度更快，15K是最好的（你可能不能）。 所有这些挂载点是否引用同一个磁盘的不同区域？ SQL Server是否与其他应用程序共享这些磁盘？ DMX上有多less写caching可用，我的testing文件是否足够大，以至于它们都不能放入caching？
（历史课：IIRC，超级老的DMX使用SCSI驱动器和（并行）总线来连接服务处理器和磁盘，一个可容纳15个磁盘的SCSI-3总线IIRC可能是饱和的IO只有3个或4个15KRPM磁盘，根本跟不上15个（甚至7个）磁盘，这就是为什么，或多或less，我们有SAS）。
SANpipe理员可能会告诉你，在DMX中有太多的写入caching，你不能压倒它。 这不一定是正确的（8年前，我曾经遇到过这样一个DMX事件，一个新的，花哨的Itanium SQL Server将数据推入其中）。 他们往往是正确的; 他们有这个意见，因为他们通常担心存储空间和利用率超过存储性能。 但是很多SANpipe理员并没有意识到SQL Server能够以多快的速度生成数据（对于testing，在一些系统表之间进行一些交叉连接并使用SELECT INTO将结果数据粘贴到临时表中，然后观察日志上的I / O文件。）
SANpipe理员也可能会告诉你，LUN下面有很多磁盘，这也是有争议的。 作为参考，请访问tpc.org，查看存储系统设置基准的方式。 请记住，一旦DMX（或其他任何东西）耗尽写入caching，系统必须依赖底层磁盘的function。
SANpipe理员应该能够判断testing是否用完写入caching，或者服务器数据所在的磁盘是否过载。
这是很多的HBA; 我从来没有超过4x4gb /秒的HBA。 您确定您没有看到PCIe背板上的某种争用或瓶颈吗？ 不同种类的PCIe具有不同的数据速率 。
你确定所有这些内核在运行sqlio时均匀地加载，而且没有一个是100％的？ 快速查看任务pipe理器会告诉你。
除此之外，我认为你需要一个SANpipe理员来查看SAN端，包括服务器和DMX之间的光纤交换机。