我最近问了很多关于这个问题的问题，我想我会放弃在这个丛林中跳动…
比方说，我有一个存储系统被用于具有不同I / O模式的各种应用程序。 我一直在收集系统的性能统计信息：
我已经计算出每个百分位数的第95百分位数，平均数和中位数。 我也知道我的平均读写比例是多less。
我知道如何计算给定磁盘，arrays和平均工作负载参数的新系统的潜在平均IOPS和吞吐量。
我正在努力把这一切放在一起。 目前观察到的统计数字受到现有体制难以跟上的限制。 因此，我可能知道我需要X IOPS，但是由于当前的磁盘瓶颈等原因，这个值可能会很低（我知道这是过度劳累，因为我看到磁盘使用量持续高速增长，而且传输时间非常长）
坦白说，我没有做任何硬核，我几乎可以买一些更快的磁盘，更好地configuration我的arrays，它会工作。 但是我想了解如何采取更正式的方法来certificate费用的合理性，而不是过度购买。
我不认为你有足够的数据…你还需要知道的是，如果IO加速，可能成为瓶颈的系统其他部分的利用率，所以你可以估计你必须走多远IO成为CPU，总线或networking之前的限制。
“足够快”的一些定义也会有所帮助。 但是这听起来像是你想要长时间等待IO消失。 根据你在做什么，你可能只是没有足够的内存来正确caching。
我原则上同意Andrew McGregor的回答，但实际情况是，在解开磁盘瓶颈之后，您可能没有奢望去执行任何types的基准testing，以查看下一个瓶颈。 在一个完美的世界中，您可以（a）以“演示”的方式访问更快的磁盘子系统，以便随时运行当前的工作负载，或者（b）可以导出从当前环境捕获的跟踪数据，通过应用软件的“神奇”math模型运行它，以绘制下一个瓶颈。
您不可能获得演示硬件，也不存在用于“回放”您的Exchange工作负载的实时跟踪的math模型（我阅读了其他问题）。 发现你的下一个瓶颈将会以任何客观的方式发生，最好是非常困难。 考虑到这一点，我会做你所知道的将提高性能和计划更高性能的磁盘。 除此之外还会有另外一个瓶颈，但除非你能find一个经济可行的方法来预测它，否则你只是在猜测。
（我正在标记这个“社区维基”，因为我真的宁愿留下它作为评论安德鲁的答案，但显然，不能发表评论这么长时间…）
一定要做我称之为理论驱动math来获得最大IOPS，并根据实际使用情况减less20％或更多。 这取决于制造商，磁盘速度等，然后与新的驱动器configuration进行比较，并确保您的峰值负载符合此限制。