基准SQL服务器性能应该监视什么

这里是我监视的计数器和为什么（请参阅perfmon中的解释button以详细解释他们所做的事情）。 请注意，许多这些计数器是无用的，除非你有一个基准来衡量。 在出现性能问题之前，您必须监视应用程序。

过程对象：处理器时间百分比 – 如果您有增长，并且此计数器平均为80％，则需要升级。 平均75-80％是一个充分利用的服务器。 特别是在用户连接数量低的情况下，持续高峰可能意味着写入的查询效果不佳，或者意味着是时候进行升级了，最好是有人偷看代码。

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

内存对象：页数/秒 – 一般来说，增加内存（或分配更多的SQL）应该降低这个计数器。 这个计数器本身并不表示性能问题。 这个柜台是主观的。 什么是告诉是，如果随着时间的推移这个上升和性能下降，当然是分配更多的内存到SQL Server的时间。 作为一个非常普遍的规则，假设sql server是框中唯一的应用程序，这个数字在24小时内应该平均为0（尖峰）。 从20岁以下的angular度来看，20岁以下的人不会真正被注意到，超过20岁，你可能需要更多的内存

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

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

物理磁盘对象：％空闲时间 – 使用这个 – 100，更准确地查看％磁盘时间（这是我的老笔记，在widows 2008下可能已经修复，但是在2000和2003有一些问题）你正在调整你想知道读取与写入的比率 – 这只是基础性能

networking接口对象：字节总数/秒 – 您正在寻找networking问题在这里。 如果它非常低（比如在20％的范围内），并且你有体面的负载，请查看networkingconfiguration，同样如果超过60％，则会出现错误configuration或networking瓶颈。 60％应该在3000个批次请求/秒左右

SQL Server的访问方法对象：完整的扫描/秒 – 如果你看到很多这些SQL服务器索引没有被使用，findSQL开发人员，并带来一个蝙蝠（使用木材作为铝的倾向于削弱），请注意，这是相对的到底线，因为并不是所有的查询都可以使用一个索引 – 但是肯定值得让开发者看看是否有任何额外的索引可以完成

SQL Server数据库对象：Transactions / Sec – 使用它来说明服务器的平均利用率，这将随着性能趋势的下降而趋于上升（注意：SQLServer：SQL统计：批量请求/秒更准确，我发现TPS更有用）

SQL Server缓冲区pipe理器对象：缓冲区高速caching命中率 – 正如你所猜测的越高越好，更多内存应该（但不一定）增加

SQL Server的一般统计对象：用户连接 – 用于更多的趋势比实际performance，基于Java的应用程序往往会泵这高达1000的由于其连接到SQL Server的方式

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