应该监视什么以获取基线 sql server 性能

Question

用于监视 SQL Server 的基准性能计数器是什么？它们的含义是什么？

Answer 1

以下是我监控的计数器及其原因（请参阅 perfmon 中的解释按钮以了解它们的作用的详细说明）。请注意，这些计数器中的许多都是无用的，除非您有一个可以衡量的基准。您必须在应用程序出现性能问题之前对其进行监控。

Process Object:% Processor Time - 如果您有增长并且此计数器平均为 80%，则该升级了。平均 75-80% 是充分利用的服务器。持续的峰值，尤其是在用户连接数较低的情况下，可能意味着查询写得不好，或者可能意味着是时候升级了，让某人查看代码当然更好。

系统对象：处理器队列长度 - 此值应小于系统中 CPU 数量的 2 倍。如果它正在增长并且 CPU %（以上）为 80%+，那么您可能需要更多或更快的处理器

内存对象：页数/秒 - 通常，添加内存（或为 SQL 分配更多内存）应降低此计数器。此计数器本身并不表示性能问题。这个计数器是主观的。说明的是，如果随着时间的推移这种情况上升而性能下降，那么肯定是时候为 sql server 分配更多的内存了。作为一个非常普遍的规则，假设 sql server 是盒子上唯一的应用程序，这个数字应该在 24 小时内平均为 0（有峰值）。从性能的角度来看，低于 20 不应该被真正注意到，超过 20 并且您可能需要更多内存

内存对象：可用 MBytes - 随着时间的推移寻找一致性 - 不是一个神奇的数字，理论上的完美世界这将尽可能接近 0

物理磁盘对象：平均。磁盘队列长度 - 一个好的经验法则是不高于心轴数 X 2，这个数字是主观的

PhysicalDisk Object:% Idle Time - 使用这个 - 100，以更准确地查看 %disk 时间（这是我的旧笔记，在 2008 年的寡妇下这可能已修复，但 2000 和 2003 年存在一些问题）如果您正在调整您想知道读取与写入的比率 - 这只是基本性能

网络接口对象：总字节数/秒 - 您正在此处查找网络问题。如果它异常低（比如在 20% 范围内）并且您有不错的负载，请查看网络配置，同样，如果它超过 60%，您可能有配置错误或网络瓶颈。60% 应该是大约 3000 批请求/秒

SQL Server 访问方法对象：Full Scans/Sec - 如果您发现许多这些 SQL Server 索引没有被使用，请找到 sql 开发人员并带上一只蝙蝠（使用木头，因为铝制的容易凹陷），请注意这是相对的到基线，因为并非所有查询都可以使用索引 - 但肯定值得让开发人员查看是否有任何可以完成的额外索引

SQL Server 数据库对象：事务/秒 - 使用它来告诉服务器的平均利用率，随着性能趋势的下降，这将呈上升趋势（请注意，SQLServer：SQL 统计：批处理请求/秒更准确，但是我发现TPS更有用）

SQL Server Buffer Manager Object:Buffer Cache Hit Ratio - 正如你猜的那样，越高越好，更多的 ram 应该（但不一定）增加这个

SQL Server 通用统计对象：用户连接 - 更多地用于趋势而不是实际性能，基于 Java 的应用程序通常会因为它连接到 sql server 的方式而将其提升到 1000

SQL Server 锁定对象：平均等待时间 - 再次主观，随着时间的推移指示性能趋势/问题，但这对于个别问题也很有用（例如，为什么此报告运行如此缓慢），如果此峰值让开发人员查看背后的代码那个特别的报告。它可能只是创建了很多锁或者它可能需要调整（所以这次把蝙蝠留在你的桌子上）