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

Question

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

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

如何估计这些数据库存储上的实际读取要求？我非常确定实际的物理读取量将远低于此，但我如何估计呢？当然，我无法在生产环境中进行实际运行，因为生产环境还不存在，我需要告诉硬件人员我们系统需要多少 IOPS，以便他们知道要做什么买。

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

编辑：主要只读数据集（大多数查询将在其中进行）是磁盘上的几个 gig（数量级为 4gig）。这可能会显着影响逻辑读取与物理读取。有什么见解如何获得这个比率吗？

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 的差异。