客户在RAID-50中使用16 X 450GB 10K的PS6000X SAN时Sybase SEE 15性能较差。 服务器是在ESX 4.0.0,256968中运行2003服务器R2 64位的Dell R710
我使用sqlio来testing驱动器上4KB块的顺序写入性能。
sqlio -kW -t1 -s600 -dE -o1 -fsequential -b4 -BH -LS sqliotestfile.dat 结果是1900 IOPS。 但是，当Sybase运行小插入的持续工作负载时，SAN HQ显示一致的590 IOPS（以及100％的4K写入活动）。 它还显示写入延迟从<1ms增加到1.2ms。
Sybase中的监视和testing表明性能问题与IO相关，特别是写入日志的等待时间很长。
SAN表示写入caching已启用。
对于4k顺序写入活动，SAN应该具备哪些IOPS？ 而且，在启用写入caching的情况下，控制器不应该将4K写入写入更高效的东西吗？
此外，任何技巧在ESX上的Sybase将不胜感激。
我希望顺序IO比你看到的更快，但是持续4K 100％的随机写IO将会在500-600IOPS左右（假设14个活动磁盘，10K SAS，RAID 50），所以我想问你怎么确定卷上的IO模式确实是连续的？
还有什么其他的卷是由PS600X呈现，他们用什么。 Equallogicarrays并不真正允许您隔离同一arrays上的卷之间的IO模式，并且如果有另一个卷或卷从同一个正在经历随机IOstream量的磁盘中分离出来，则可能导致此问题。
首先要做的是 – testing文件的大小是否与真实数据库相当？ 如果没有，寻求时间可能是这里的区别因素 。
如果您尚未使用vmware paravirtual scsi适配器作为日志卷，我build议您给它一个旋转。 这不是一个神奇的解决方法，但某些工作负载从中受益。 通常，它会增加一点延迟，但在处理大量写入时允许更高的整体吞吐量。
如果可行的话，我意识到这是一个很大的麻烦，你可能希望考虑直接将同一台服务器的物理实例挂接到SAN中，并运行相同的testing，从而将ESX排除在外。 由于您正在阅读来自两个独立位置和产品的IOPS数据，因此我也会考虑一个可能的因素。 也就是说，我不希望这个数字会下降3倍。