估计突发使用的 IO 要求

Question

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

对于使用相对稳定的系统，我听说过观察磁盘队列长度并将该数字保持相对较小的经验法则。这将专门在 AWS 中运行，在那里我看到了一个经验法则，即每 100 IOPS 1 的磁盘队列长度是合理的。

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

Answer 1

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

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

为了测试您的 IO，您必须了解您在高峰期的工作负载。有多少交易和缓存多少？除非你知道并测量过这些，否则很难判断。您可以创建工作负载并使用SQLIO 之类的工具来测试您的存储，但您需要工作负载模式才能构建正确的测试。

最后，关于 AWS 的说明：据我所知，Amazon 不会保证 AWS 中的 IO 性能。这主要是因为存储是一个巨大的共享资源，不可能在特定的存储区域上衡量您和您的邻居的模式（请参阅嘈杂的邻居问题）。

我的建议是分配尽可能多的内存。SQL Server 只会在缓冲池中存在压力和空间（基于 LRU-K）时将内容推出内存。因此，如果您的缓冲池可以将大部分数据库存储在内存中，则可以减轻一些突发性能。另外，考虑可以保持缓存对象“温暖”的策略。最后，请关注 SQL 2014 和新的Hekaton功能。