我在 SAN 性能调优中遇到了问题。我正在使用 SQLIO 在 EMC DMX 上测试 24 个 RAID - 5 挂载点。我测试的主机有 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
我的问题是：
当我仅测试 1 个挂载点时，我看到 850MB/秒和 14k IO/秒，但当我测试多个文件时，850MB/秒是我见过的最大值。所以我相信我在某个地方遇到了瓶颈。主机中有 8 个 4 千兆光纤通道卡，所以我很难相信是那样，所以我只能“猜测”它是 HBA/SP 或 SQLIO。
我是否遗漏了某些可能成为瓶颈的东西？这是正常行为还是 SQLIO 应该汇总所有挂载点的吞吐量？
顺便提一下，为了证明 SQLIO 不是问题所在，也不是文件间“平均”带宽，我在不同的挂载点同时运行了 2 个 SQLIO 实例，每个实例的速度大约为 400mb/s。对我来说，这证明不是 SQLIO。
答案1
PowerPath（或系统中的等效物）是否已正确设置以平衡 HBA 负载？所有 HBA 是否正常工作？您应该能够访问服务器并查看 Powerpath 配置以获取这些答案。
总是值得查看 Windows 事件日志来查看是否有任何消息从 HBA 或 powerpath 弹出。
我不记得 DMX 是否使用存储池，但在查看 SAN 性能时，一些很好的基本问题是：存储分布在多少个磁盘上？通常越多越好。如果只有几个磁盘，请提出问题。只要您询问磁盘，您不妨询问 RPM 速率。速度越快越好，如果您无法获得 SSD（您可能无法获得），则 15K 是最好的。所有这些挂载点是否都引用同一磁盘的不同区域？SQL Server 是否与其他应用程序共享这些磁盘？DMX 上有多少可用的写入缓存，我的测试文件是否足够大，以至于它们不能全部放入缓存中？
（历史教训：如果我没记错的话，超旧的 DMX 使用 SCSI 驱动器和（并行！）总线将服务处理器连接到磁盘。如果我没记错的话，SCSI-3 总线最多可容纳 15 个磁盘，但 IO 仅能容纳 3 或 4 个 15KRPM 磁盘，根本无法跟上 15 个（甚至 7 个）磁盘。这就是为什么我们或多或少有 SAS。）
SAN 管理员可能会告诉您，DMX 中的写入缓存非常多，您无法使其超负荷。这不一定是真的（8 年前，我遇到过这样的 DMX 事件，当时一台新的、花哨的 Itanium SQL Server 将数据推送到其中。）。他们通常是正确的；他们有这种看法是因为他们通常更担心存储空间和利用率而不是存储性能。但许多 SAN 管理员没有意识到 SQL Server 生成数据的速度有多快（为了进行测试，在一些系统表之间进行几次交叉连接，并使用 SELECT INTO 将结果数据粘贴到临时表中，然后观察日志文件上的 I/O。）
SAN 管理员可能还会告诉您，您的 LUN 下有很多磁盘，这也值得商榷。作为参考，请访问 tpc.org 并查看存储系统设置基准测试的方式。请记住，一旦 DMX（或其他任何东西）用尽写入缓存，系统就必须依赖底层磁盘的能力。
SAN 管理员应该能够判断测试是否耗尽写入缓存或者服务器数据所在的磁盘是否超载。
这是相当多的 HBA；我从来没有超过 4x4gb/sec 的 HBA。你确定你没有在 PCIe 背板上看到某种争用或瓶颈吗？不同类型的 PCIe 有不同的数据速率。
您确定运行 sqlio 时所有核心都均衡加载，且没有一个核心达到 100% 吗？快速查看任务管理器即可找到答案。
除此之外，我认为您会希望 SAN 管理员查看 SAN 端，包括服务器和 DMX 之间的任何结构交换机。