我感觉我们的SANperformance不好，所以我在Ozar先生的博客文章的帮助下运行了SQLIO。
我的第一个问题是我无法创build一个20GB的testing文件。
这是结果
using 64KB random IOs enabling multiple I/Os per thread with 8 outstanding buffering set to use hardware disk cache (but not file cache) using current size: 2011 MB for file: M:\TestFile.dat initialization done CUMULATIVE DATA: throughput metrics: IOs/sec: 3873.51 MBs/sec: 242.09 latency metrics: Min_Latency(ms): 0 Avg_Latency(ms): 16 Max_Latency(ms): 1465 histogram: ms: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+ %: 3 2 3 3 4 5 5 5 5 5 5 5 5 5 4 4 4 3 3 2 2 2 2 1 13 using 64KB sequential IOs enabling multiple I/Os per thread with 8 outstanding buffering set to use hardware disk cache (but not file cache) using current size: 2011 MB for file: M:\TestFile.dat initialization done CUMULATIVE DATA: throughput metrics: IOs/sec: 5279.99 MBs/sec: 329.99 latency metrics: Min_Latency(ms): 0 Avg_Latency(ms): 11 Max_Latency(ms): 267 histogram: ms: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24+ %: 1 1 3 5 11 8 6 5 4 4 5 7 7 6 5 4 3 3 2 2 1 1 1 1 4 关于SAN的指标可以说些什么？
我应该考虑另一个提供者？
SAN被认为是“最先进的HP SAN”。
如果您的SAN真的是最新的技术，您将在磁盘和SSD之间进行自动分层。 对SSD所做的任何工作的性能将比对磁盘快得多。 此外，你将有很多的caching，这意味着写甚至不会触及磁盘/ SSD通常。 我假设你在谈论p9500，但是如果这个假设是错误的，你应该真的编辑你的问题，以获得更多关于你的configuration的信息。
如果你正在testing读取（这是更典型的），那么你会想尝试隔离基于池组成的空间。 将您的文件所在的LDEV放在一个拥有更多主轴或更高比例SSD的池中，并且应该更快。
所有这一切，唯一重要的指标是当你在所有的气瓶上射击时的延迟。 任何机器在利用不足时都可以快速运行，但是一旦运行了大量的同时运行的应用程序，就可以看一看。 我的build议是在更多的服务器上模拟更多的IO，并在延迟超过10ms之前查看可以产生多lessIO。 在生成负载时，您希望具有与实际工作负载相同的读取和顺序随机比率。 如果不这样做，你需要70％的读取到30％的写入，以及20％的顺序到80％的随机。
关于SAN的指标可以说些什么？
没有。
使用当前的大小：2011 MB
这不是一个现实的考验。 SAN可能有一个写回caching，并且您的文件非常繁忙，足够小，可以被逐块完全caching。 所以，你没有真正衡量任何有价值的东西。
这就像是在前10米的加速度下测量汽车的最高速度。 没有工作。
考虑到硬件和工作量，您的testing文件必须符合实际。 这意味着，如果typciall有一个非繁忙的SAN和一个小的数据集，那么你可以在prouction sizetesting文件上运行这个文件 – 至less有一个比所涉及的caching大一些。 因此，在单独为您提供32GB SANcaching（在HP EVA上可见）的情况下，最好使用128GB的testing文件。
IOs /秒：3873.51
这是一个高端的SAN或一个体面的caching。 每个磁盘给定450 IOPS，这意味着您可以独立运行7-8张光盘。 可以 – 或者可以像我说的那样从caching中运行。