SQLIO性能测试问题

Question

我遇到一个问题，性能调优SAN。我正在测试24个挂载点，它们是RAID -5在一个使用SQLIO的EMC DMX上。我正在测试的主机有256 32的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

我的问题是：

当我测试一个挂载点时，我会看到850 is /秒和14k IOs/Sec，但是当我测试多个文件时，850 is/秒是我见过的最多的。所以我想我在某个地方遇到了瓶颈。主机中有8G的光纤通道卡，所以我很难相信它是这样的，所以我只能“猜测”它是HBA/SP或SQLIO。

我错过了什么东西可能是瓶颈吗？这是正常行为还是SQLIO应该在所有挂载点上聚合吞吐量？

顺便指出，为了证明SQLIO不是问题，也不是“平均”跨文件的带宽，我在不同的挂载点上同时运行了两个SQLIO实例，并在每个挂载点上看到了大约400 of /S。对我来说，这证明了它不是SQLIO。

Answer 1

是否设置了PowerPath (或您的系统中等效的)以正确地负载平衡HBAs？所有的HBA是否都能正常工作？您应该能够弹出服务器并查看Powerpath配置以获得这些答案。

始终值得在windows事件日志中查看是否有任何消息从HBA或powerpath中弹出。

我不记得DMX是否使用存储池，但是在查看SAN性能时，一些好的基本问题是:存储分布在多少个磁盘上？更多通常更好。如果只是几个磁盘，就质疑它。只要你在询问磁盘，你就可以询问RPM的速率。更快是更好，而15K是最好的，如果你不能得到SSD (而你可能不能)。所有这些安装点是否都引用同一磁盘的不同区域(S)？Server是否与其他应用程序共享这些磁盘？DMX上有多少写缓存可用，我的测试文件是否足够大，以至于它们都不适合缓存？

(历史教训: IIRC，超级老DMXes使用SCSI驱动器和(并行！)连接服务处理器(S)到磁盘的总线。IIRC是一种SCSI-3总线，它可以容纳最多15个磁盘，只需要3或4个15 15KRPM磁盘就能被IO饱和，根本无法跟上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/秒的HBAs。您确定您没有在PCIe背板上看到某种争用或瓶颈？不同种类的PCIe有不同的数据速率。

当您运行sqlio时，您确定所有这些内核都是平均加载的，并且没有一个达到100%吗？快速查看任务管理器将告诉您。

除此之外，我认为您需要一个SAN管理员来查看SAN端，包括服务器和DMX之间的任何fabric开关。