解释SQLIO测试结果

Question

我一直在一个生产前集群的专用DB SAN上运行一系列负载测试(戴尔R710通过2G以太网连接到专用的RAID10 SAN )，我不确定我是否正确地解释了这些数据。

供参考，这是原始数据。

测试1

sqlio v1.5.SG
using system counter for latency timings, 2727587 counts per second
parameter file used: paramD100.txt
    file d:\tmp\testfile.dat with 2 threads (0-1) using mask 0x0 (0)
2 threads reading for 120 secs from file d:\tmp\testfile.dat
    using 64KB random IOs
    enabling multiple I/Os per thread with 2 outstanding
    buffering set to use hardware disk cache (but not file cache)
using specified size: 20480 MB for file: d:\tmp\testfile.dat
initialization done
CUMULATIVE DATA:
throughput metrics:
IOs/sec:   372.12
MBs/sec:    23.25
latency metrics:
Min_Latency(ms): 1
Avg_Latency(ms): 10
Max_Latency(ms): 159

测试2

sqlio v1.5.SG
using system counter for latency timings, 2727587 counts per second
parameter file used: paramD100.txt
    file d:\tmp\testfile.dat with 2 threads (0-1) using mask 0x0 (0)
2 threads reading for 120 secs from file d:\tmp\testfile.dat
    using 64KB random IOs
    enabling multiple I/Os per thread with 2 outstanding
    buffering set to use hardware disk cache (but not file cache)
using specified size: 20480 MB for file: d:\tmp\testfile.dat
initialization done
CUMULATIVE DATA:
throughput metrics:
IOs/sec:   358.26
MBs/sec:    22.39
latency metrics:
Min_Latency(ms): 1
Avg_Latency(ms): 10
Max_Latency(ms): 169

为了减少试验结果之间的差异，本试验连续2天于上午11:30进行。

考虑到这种负载模式，我是否应该期望获得尽可能低的MBPS吞吐量，或者我是否正确地解释了这一点，并相信网络或SAN (或整个集群)都有问题？

谢谢。

更新#1

为了给出具体的内容，设置如下。

产品数据库集群

戴尔R710，与2xBroadcom5709‘S (iSCSI和脚趾卸载能力，使用戴尔的多点IO软件)。是的，我看过“Broadcom- die mutha”的帖子:S

开关

2 Juniper EX4200-48T作为单个虚拟开关

每个集群上来自每个Broadcom的一个连接连接到一个交换机，从每个交换机到SAN有2Gigabit连接。

SAN

戴尔EqualLogic PS6000E iSCSI SAN，配有16 (14 +2热备用) 2tb 7200 2tb驱动器

据我所知，从我认为应该如何工作，理论上我们应该得到200 this，正如你所看到的，我们不是。

更新2

为了提供更多的上下文，这里有一个图表显示了4次单独运行的平均mbps。

作为参考，Y轴是MBPS，X轴是IO类型(随机或顺序)，待定IO和操作(读和写)。

图像已禁用，下面是链接- 显示4次SQLIO运行的平均结果的图表

我在这里有两件事-

• 首先，随机读取吞吐量比我预期的要低。
• 其次，随机写入IO平台在110 more，而这建议数组应该有能力更多。

这是这类设置的大致预期模式吗？这里还有什么地方看上去不对劲吗？

Answer 1

理论上我们应该达到200 should

在你的梦里。当不做随机IO时，msot的时间是从一个部门跳到另一个部门。但是随机的io和很少的慢终端用户光盘听起来是对的-欢迎来到一个世界，在那里你可以得到大约300个IOPS的一对磁盘，而SSD给你60.000。现在您可能已经了解到，SSD是一个用于随机IO的SAN，而最终用户喜欢osm的MB/S数字与数据库存储后端没有任何关系。

你还破坏是：

为每个线程启用多个I/O，其中2个未完成

好的，考虑到SATA (本机命令队列)智能地重新排序最多32个待决请求，同时只发送2个请求是次优的。您可以得到2x2 =4突出，但可以处理每个磁盘32。

他说，最后你需要(a)更快的光盘(b)更多的，以获得更高的IOPS。或者一个像样的二级缓存(Adaptec raid控件可以使用SSD作为读/写缓存)。

Answer 2

不，你说得对，这一点也不太好--你没有提到SAN的布局，但考虑到它是R10，那么你会想到一个最坏的情况，那就是在1Gbps链路上至少有4张便宜的SATA磁盘(因为MAC一致性，我怀疑这两者都会同时使用)，即使这样，我也希望至少是你所看到的随机读取MBps的两倍，这是最坏的情况。出了点问题。

Answer 3

由于您没有提到SAN是什么，我将假设它是通用的iSCSI。

里面有什么样的磁盘？什么速度？什么缓存，如果有的话，在RAID-10？

我同意22 be /秒的速度非常慢，但是如果RAID-10中只有4个SATA磁盘，那么350多个IOPS将是正确的。