在某些方面，我想这是一个string问题，但即使有一个“这适合大多数情况下”的答案我不知道它是什么，所以…
我有一个惠普P4000评估的SAN。 我想用IOMeter做一些基准testing，看看它的能力。
但是，我不知道块大小，读/写分割和随机/顺序分割的组合适用于不同的用途。
例如，你将如何模拟一些Exchange活动，一些SQL活动，一些一般的VM活动等等。
我知道如何添加工作人员并将其设置为不同的设置，但是我应该使用哪些设置？
谢谢。
Exchange和SQL活动趋向于频繁，更小的IO / Ops结尾。 随着附件被写入/拉出，Exchange有相当多的I / O突发。 备份间隔和长时间运行的查询可以真正玩滚刀，也可能是您的高峰I / O实例。 Exchange Online碎片整理是Exchange的IO峰值，SQL备份是我们SQL服务器的I / O峰值。
Exchange Online碎片整理涉及很多I / O操作，但吞吐量并不高，所以平均传输大小很小，512b很小，而且其中很多。 读/写比率变化很大，但对于维护良好的Exchange DB，它应该大部分读取。 这将是显着的随机性，但足够的顺序访问保持有趣（没有我没有确切的比例）。
SQL备份涉及多种规模，但与在线碎片整理不同，吞吐量实际上也很高。 计划混合512b到4kb传输大小。 读写比例取决于数据的结束位置！ 写入速度可能非常快，但（取决于备份脚本）几乎完全是顺序的。 读数将是100％随机的。
常规虚拟机活动取决于虚拟机中的内容。 如果你有Exchange或SQL，那么监控一下。 如果一般来说，你的意思是“一般文件服务”，如networking或CIFS共享，那么取决于他们在做什么; CAD工程师与完全采购办公室职员的办公室有着非常不同的访问模式。 “通用虚拟机活动”没有通用的I / O模式。 你必须计划你在虚拟机中实际拥有的东西。
使用Iometer进行存储系统性能分析： http : //communities.vmware.com/docs/DOC-3961
在SQL Server框中，您最好使用以下参数testing磁盘，具体取决于将要存储MDF，NDF，LDF和TEMPDB文件的位置：
你可以改变随机读取的百分比，看看你的结果是否有所不同，但我发现上述值是一个很好的起点。
SQL Server最佳实践文章（MSDN）
testing读/写和顺序/随机I / O大小的组合。 对于以SQL为中心的部署，确保为顺序I / O包含8 KB，64 KB，128 KB，256 KB和1024的I / O大小。 （运行SQL Server企业版时，预读可以高达1024 KB）。 对于随机I / O，只关注8-KB I / O通常是安全的。
SQL Server中缓慢的磁盘I / O故障排除（博客MSDN）
如果您怀疑磁盘性能不佳，则可以将内部DMV与性能监视器集合结合使用，以便更好地了解磁盘I / O子系统的运行状况，以及SQL Server遇到的性能低下的任何延迟。
SQL Server Perfmon（性能监视器）最佳实践（Brent Ozar）
在“性能对象”下拉列表中，select“物理磁盘”，然后select“％磁盘时间”计数器。 再次注意，在右侧窗口，我们得到多个实例; 这一次，我们得到一个物理磁盘。 在性能方面，物理磁盘是指计算机pipe理的磁盘pipe理工具中显示的一个磁盘。 一个物理磁盘可能有多个分区，每个分区都有自己的驱动器号，但为了性能调整，我们想知道一个物理磁盘有多难。
这个“物理磁盘”可能有一堆实际的物理驱动器，就像在RAID系统中一样。 但是，Windows不够聪明，无法确切知道RAIDarrays中有多less个驱动器，因此术语“物理磁盘”在这里有点误导。
如何从SQL Server内部检查IO子系统延迟（SQLSkills）
今天大多数SQL Server都是I / O绑定的 – 这是数据库pipe理员和现场顾问普遍认可的声明。 这意味着服务器性能的主要因素是能够快速执行I / O操作。 如果I / O子系统跟不上需求，那么SQL Server工作负载将会出现性能问题。
现在说，很多人陷入的陷阱就是增加了I / O子系统延迟和I / O子系统性能差。 这通常不是这种情况。 通常，I / O子系统在devise的I / O工作负载发生时性能良好，但在I / O工作负载增加超过I / O子系统devise点时成为性能瓶颈。 I / O工作负载的增加是导致问题的原因，而不是I / O子系统 – 如果deviseI / O子系统以支持1000 IOPS（每秒I / O操作），并确保使用正确的I / O大小和工作负载特性是有意义的，以随机IOPS的数量来定义），SQL Server正在试图推动2000 IOPS，性能将受到影响。