典型的SAN性能是什么？

我们有一台EVA6100，所以我在类似的硬件上做了testing。 8000是IIRC，比6100老一点。

首先，对数据库卷和日志卷的写入很有可能争夺写入，因为它听起来像是在EVA中的同一个磁盘组上。 磁盘组是指您创buildLUN的磁盘组，每个LUN都是提供给一个（或多个）服务器的磁盘。 在一个磁盘组中容纳很多很多的LUN并不罕见。 如果只有一个磁盘组，那么将日志I / O从数据库I / O中分离出来的好处有所减less。

其次，如果DG正在进入真正的I / O竞争状态，则会降低性能。 从消费者的angular度来看，这是非常难以检查的，这是SAN维护人员需要注意的事情。 询问他们是否知道平均控制器CPU负载是多less，因为这会显着影响写入性能。

第三，知道你的I / O组合真的是一个基准，而不仅仅是文件拷贝的速度。 如果您的数据库卷I / O是80/20读/写，那么您确实需要检查读取path吞吐量。 如果是相反的话，那么你的写作performance就是你真正需要检查的指标。

通过简单地写一个大文件，您不会测量存储性能。 你只是衡量写一个大文件的性能。 如果你认为自己会得到类似的东西，那么你很遗憾错误地认为：随机写入整个磁盘，同时写很多块，写很大或者很小的块。 我向你保证，你可以在一个types的工作负载上拥有最大1 MB / s的数据，然后在另一个工作负载/设置下，你将很容易获得800 MB / s的数据（如果你的服务器可以处理的话）。

如果你想了解这些，使用适当的工具。 当时我使用了Intel IOMeter，并且学到了很多东西。 现在可能有一些更好的工具。 要注意的主要参数是队列大小和随机与顺序操作。 阅读关于磁盘机制，为什么寻道时间是如此令人难以置信的缓慢，以及如何RAID5function。

如果您想知道您的存储在现实生活中的performance如何，请在工作date间查看perfmon.exe中的PhysicalDisk计数器。 然后在实际的应用程序上创build一些负载并观察发生的情况。

另一个重要的事情是检查是否正确的磁盘alignment。 不止一次，我看到不alignment的LUN是性能问题的根源。 如果格式化之前分区上的偏移量未设置，则可以在IO上看到25％的性能命中。

至less对于日志LUN，RAID 10也是更好的select。

最后，您可以将LUN上的读/写高速caching比率调整为100％写入，因为SQL Server对读取进行高速caching非常有效。

SQLIO是基准testing的一个很好的工具，但绝对不是用于生产的。 它易于使用，运行顺序和随机的读/写testing的可变大小，并作出一个很好的基准来比较其他系统。

看看RAID10。 一位聪明的同事曾经说服我，写入密集型数据库比RAID5更好，他是对的。 它是。

它看起来非常低，当你考虑到它们是为了使用方便而构build的时候，EVA8xxx盒子非常快。 我们有很多的东西，我有一个备用的8100和112 * 1TB的7.2K磁盘，我可以很容易地吞吐一个4Gbps的FC连接，即使是在一个RAID5的虚拟磁盘 – 大约385MBps。

我想事情已经到来，我很乐意提供帮助，但可能需要一段时间，如果你和惠普有足够的关系，那么你最好让惠普进入。

让我知道你怎么样。

SAN中有什么样的磁盘（光纤通道，SATA等），可以对你获得的速度产生重大影响。 另外，当你正在做的testing我把它从直接连接到SAN的服务器复制？