我们正在开发一个每天为数千名用户提供服务的应用程序（其中90％将在工作时间内处于活动状态，在工作日期间不断使用系统）。该系统的主要目的是查询多个数据库，并将来自数据库的信息组合成对用户的单个响应。根据用户输入，对于具有1000个用户的系统，我们的查询负载可能大约为每秒500个查询。这些查询中有80％是读取查询。
现在，我使用SQL Server Profiler工具进行了一些分析，并且我平均读取了大约300个读取查询的逻辑读取（我还没有理解写入查询）。对于1k用户，这相当于每秒150k次逻辑读取。全生产系统预计拥有~10k用户。
如何估算这些数据库的实际存储读取要求？我很确定实际的物理读取量会远远低于此值，但我如何估计呢？当然，我不能在生产环境中进行实际运行，因为还没有生产环境，我需要告诉硬件人员系统需要多少IOPS才能知道该怎么做买。
我尝试了之前答案中建议的HP调整工具，但它仅建议惠普产品，没有实际的性能估算。任何见解都表示赞赏。
编辑：主要的只读数据集（大多数查询将在其中）是磁盘上的两个演出（数量级4gig）。这可能会显着影响逻辑与物理读取。有任何见解如何获得这个比例？
答案 0 :(得分：2)
磁盘I / O需求因许多因素而异，包括：
出于这些原因，估算生产磁盘负载的最佳方法通常是构建一个小型原型并对其进行基准测试。如果可以，请使用生产数据的副本;否则，使用数据生成工具来构建类似大小的数据库。
使用示例数据，构建一个简单的基准测试应用程序，可以生成您期望的各种类型的查询。如果需要，可以缩放内存大小。
使用Windows性能计数器测量结果。最有用的统计数据是物理磁盘：每次传输的时间，每秒传输，队列深度等。
然后，您可以对这些结果应用一些启发式（也称为“经验”），并将其推断为生产I / O要求的第一次估算。
如果您绝对无法构建原型，那么可以根据初始测量结果进行一些有根据的猜测，但它仍然需要工作。对于初学者，请启用统计信息：
SET STATISTICS IO ON
在运行测试查询之前，请清除RAM缓存：
CHECKPOINT
DBCC DROPCLEANBUFFERS
然后，运行查询，查看物理读取+预读读取以查看物理磁盘I / O需求。重复一些混合而不先清除RAM缓存，以了解缓存有多大帮助。
话虽如此，我建议不要单独使用IOPS作为目标。我意识到SAN供应商和IT经理似乎喜欢 IOPS，但他们是一个非常误导性的磁盘子系统性能衡量标准。例如，当您从顺序I / O切换到随机时，可交付IOPS可能有40：1的差异。
答案 1 :(得分：0)
您当然无法从逻辑读取中推导出您的估算值。这个计数器确实没那么有用，因为通常不清楚它有多少是物理的，而且每个访问的CPU成本都是未知的。我不会看这个数字 。
您需要收集虚拟文件统计信息，以显示物理IO。例如：http://sqlserverio.com/2011/02/08/gather-virtual-file-statistics-using-t-sql-tsql2sday-15/
Google for“virtual file stats sql server”。
请注意，如果您假设缓冲池的缓存命中率保持不变，则只能从用户计数中推断IO。估计这个要困难得多。基本上，您需要估算满负荷下的工作页面。
如果您可以确保缓冲池始终可以获取所有热数据，那么您基本上可以无需任何读取。然后你只需要缩放写入（例如使用SSD驱动器）。