估计生产 SQL Server 系统的 IOPS 要求

Question

我们正在开发一个每天为数千名用户提供服务的应用程序（其中 90% 的用户将在工作时间处于活动状态，并在工作日不断地使用该系统）。该系统的主要目的是查询多个数据库，并将数据库中的信息组合成一个单一的响应给用户。根据用户输入，对于一个有 1000 个用户的系统，我们的查询负载可能是每秒大约 500 个查询。这些查询中有 80% 是读取查询。

现在，我使用 SQL Server Profiler 工具进行了一些分析，我平均获得约 300 次读取查询的逻辑读取（我还没有打扰写入查询）。对于 1k 个用户，这相当于每秒 150k 逻辑读取。完整的生产系统预计将拥有约 1 万名用户。

我如何估计这些数据库对存储的实际读取需求？我很确定实际的物理读取量会比这少得多，但我该如何估计呢？当然，我不能在生产环境中实际运行，因为生产环境还没有，我需要告诉硬件人员我们需要多少 IOPS 才能让他们知道要做什么买。

我尝试了之前答案中建议的 HP 选型工具，但它只建议 HP 产品，没有实际的性能估计。任何见解都值得赞赏。

编辑：主要的只读数据集（大多数查询将去的地方）是磁盘上的几个 gigs（数量级 4gigs）。这可能会显着影响逻辑与物理读取。任何见解如何获得这个比率？

Answer 1

磁盘 I/O 需求因许多因素而有很大差异，包括：

• RAM 中已有多少数据
• 架构的结构（索引、行宽、数据类型、触发器等）
• 查询的性质（联接、多个单行与行范围等）
• 数据访问方法（ORM 与面向集合、单命令与批处理）
• 读取与写入的比率
• 磁盘（数据库、表、索引）碎片状态
• SSD 与旋转介质的使用

出于这些原因，估计生产磁盘负载的最佳方法通常是构建一个小型原型并对其进行基准测试。如果可以，请使用生产数据的副本；否则，请使用数据生成工具来构建类似大小的数据库。

使用适当的示例数据，构建一个简单的基准测试应用程序，该应用程序会生成您期望的各种类型的查询。如果需要，可以缩放内存大小。

使用 Windows 性能计数器测量结果。最有用的统计数据是物理磁盘：每次传输的时间、每秒的传输、队列深度等。

然后，您可以对这些结果应用一些启发式方法（也称为“经验”），并将它们推断为生产 I/O 要求的初步估计。

如果您绝对无法构建原型，则可以根据初始测量做出一些有根据的猜测，但这仍然需要努力。对于初学者，请打开统计信息：

SET STATISTICS IO ON

在运行测试查询之前，清除 RAM 缓存：

CHECKPOINT
DBCC DROPCLEANBUFFERS

然后，运行查询，查看物理读取 + 预读以查看物理磁盘 I/O 需求。在不先清除 RAM 缓存的情况下重复一些混合操作，以了解缓存有多大帮助。

话虽如此，我还是建议不要单独使用 IOPS 作为目标。我意识到 SAN 供应商和 IT 经理似乎喜欢 IOPS，但它们是磁盘子系统性能的一个非常误导性的衡量标准。例如，当您从顺序 I/O 切换到随机 I/O 时，可交付的 IOPS 可能存在 40:1 的差异。

Answer 2

您当然无法从逻辑读取中得出您的估计。这个计数器实际上并没有那么有用，因为通常不清楚其中有多少是物理的，而且每个访问的 CPU 成本也是未知的。我根本不看这个数字。

您需要收集虚拟文件统计信息，以显示物理 IO。例如：http://sqlserverio.com/2011/02/08/gather-virtual-file-statistics-using-t-sql-tsql2sday-15/

谷歌搜索“虚拟文件统计 sql server”。

请注意，如果您假设缓冲池的缓存命中率保持不变，则只能从用户数推断 IO。估计这一点要困难得多。基本上，您需要估计在满负荷下您将拥有的工作页面集。

如果您可以确保您的缓冲池始终可以获取所有热数据，那么您基本上可以在没有任何读取的情况下生存。然后您只需要扩展写入（例如使用 SSD 驱动器）。