估计突发使用的IO需求

我们有一个可以全天定期查询SQL数据库的应用程序。有零个活动周期或只有零个活动周期，并散布着对相对大量数据的单独请求。当这些请求出现时，主要目标是快速交付数据，次要目标是经济高效地完成数据处理。由于应用程序的性质，数据/索引不太可能会从先前的查询（不同的用户，在数据的不同部分上）缓存到RAM中。

对于使用率相对稳定的系统，我听说过经验法则以观察磁盘队列长度并使该数量保持较小。这将特别在AWS中运行，在该AWS中，我已经看到一条经验法则，即磁盘队列长度为每100 IOPS 1个是合理的。

我如何估算此类系统的IO要求？在处理单个突发查询时，磁盘队列长度是否是可靠的指标？我还应该考虑其他指标吗？

我一直在考虑在SQL Server中使用IO的主要指标不是IOP或磁盘队列长度，而是磁盘吞吐量（秒/读取和秒/写入）。总体而言，数据库不是关于可以在磁盘上进行多少操作的信息，而是关于这些操作完成的速度。一般的经验法则是每次操作少于20毫秒（尽管越低越好）。可以在本文中找到更多详细信息。

磁盘队列长度是虚假的统计信息，不再相关。它的问题在于该值可以衡量单个驱动器的队列，但是由于我们生活在RAID，SAN和其他分布式存储的时代，因此无法正确地将该值转换为有意义的数字。Quest / Dell的这张海报是性能指标的一个很好的起点，它为您提供了很多关于为什么重要或为什么不重要的内容和解释。您不必全部使用它们，但是它们只是一个开始。

为了测试您的IO，您必须了解峰值时的工作量。多少事务和多少缓存？除非您知道并测量了这些，否则很难判断。您可以创建工作负载并使用SQLIO之类的工具来测试您的存储，但是您将需要工作负载模式才能构建适当的测试。

最后，关于AWS的注释：据我所知，Amazon将不保证AWS中的IO性能。这主要是因为存储是海量的共享资源，无法衡量您和您在特定存储区域上的邻居的模式（请参阅“ 嘈杂的邻居问题”）。

我的建议是分配尽可能多的内存。SQL Server仅在缓冲池（基于LRU-K）处于压力和空间不足的情况下才将其推出内存。因此，如果您的缓冲池可以将大多数数据库存储在内存中，则可以减轻某些突发性能。另外，请考虑可以使高速缓存对象保持“温暖”状态的策略。最后，请密切注意SQL 2014和新的Hekaton功能。