☰

带有 SQL Server 的性能监视器 - 多少个计数器才算太多？

tag-icon • tag-icon windows sql-server sql-server-2008 performance performance-monitoring
带有 SQL Server 的性能监视器 - 多少个计数器才算太多？

我正在使用内置的 Windows 性能监视器对通用硬件和 SQL Server 进行一些性能分析。我阅读了很多关于使用哪些性能计数器的文章；特别是这个文件等待和排队的方法很棒。

然而，它推荐了太多的计数器，我担心如果计数器太多，要么我的生产服务器就会崩溃，要么结果会过于偏差而无法获得准确的读数。

我不太清楚究竟发生了什么，以致于生成或收集这些统计数据 - 它们通常会给系统增加什么样的负载？我知道，答案是“视硬件和当前负载而定”，但总的来说，我想知道对于多少才算太多，是否有共识 - 一次 20、50、100 或更多？

编辑：如果有相关性，我目前配置了 41 个计数器：

\Memory\Page Faults/sec
\Memory\Pages/sec
\PhysicalDisk(_Total)\% Disk Time
\PhysicalDisk(_Total)\Avg. Disk Queue Length
\PhysicalDisk(_Total)\Disk Reads/sec
\PhysicalDisk(_Total)\Disk Writes/sec
\Process(sqlservr)\% Privileged Time
\Process(sqlservr)\% Processor Time
\Process(sqlservr)\% User Time
\Process(sqlservr)\Page Faults/sec
\Processor(_Total)\% Processor Time
\Processor(_Total)\Interrupts/sec
\System\Processor Queue Length
\SQLServer:Access Methods\Full Scans/sec
\SQLServer:Access Methods\Index Searches/sec
\SQLServer:Access Methods\Page Splits/sec
\SQLServer:Buffer Manager\Buffer cache hit ratio
\SQLServer:Buffer Manager\Checkpoint pages/sec
\SQLServer:Buffer Manager\Lazy writes/sec
\SQLServer:Buffer Manager\Page life expectancy
\SQLServer:Buffer Manager\Page reads/sec
\SQLServer:Buffer Manager\Page writes/sec
\SQLServer:Databases(_Total)\Log Flush Wait Time
\SQLServer:Databases(_Total)\Log Flush Waits/sec
\SQLServer:Databases(_Total)\Transactions/sec
\SQLServer:General Statistics\User Connections
\SQLServer:Latches\Average Latch Wait Time (ms)
\SQLServer:Latches\Latch Waits/sec
\SQLServer:Locks\Average Wait Time (ms)
\SQLServer:Locks(_Total)\Lock Wait Time (ms)
\SQLServer:Locks(_Total)\Lock Waits/sec
\SQLServer:Memory Manager\Memory Grants Pending
\SQLServer:Memory Manager\Memory Grants Outstanding
\SQLServer:Memory Manager\Target Server Memory (KB)
\SQLServer:Memory Manager\Total Server Memory (KB)
\SQLServer:Plan Cache\Cache Hit Ratio
\SQLServer:SQL Statistics\SQL Compilations/sec
\SQLServer:SQL Statistics\SQL Re-Compilations/sec
\SQLServer:SQL Statistics\Batch Requests/sec
\SQLServer:SQL Statistics\Auto-Param Attempts/sec
\SQLServer:SQL Statistics\Failed Auto-Params/sec

答案1

我无法给出一个神奇的数字，但是我可以告诉你，性能计数器的开销非常非常低。信息已经存在，微软完全希望你使用和收集它们。机器不必费尽心思来生成它们，它所做的只是捕获它们，而不是在你选择添加它们时让它们溜走。我可以告诉你，我们的生产机器上有 75 个，负载没有差异。

答案2

除非你每秒捕获 1000 个计数器，否则我认为你不会看到服务器性能下降。我的建议：专注于你将如何使用他们。

我在 Excel 中分析我的跟踪结果，因此我总是将其保存为 CSV 格式，并确保捕获的计数器少于 255 个（由于 Excel 中的列限制）。

您可能需要花一些时间才能确定哪些计数器对您有用，但一旦确定，捕获额外的列对您没有任何好处。例如，我曾经捕获所有 PhysicalDisk 计数器，直到我了解到对我最有用的是 Avg Disk Sec/Read、Avg Disk Sec/Write（用于测量延迟）以及 Disk Reads/sec、Disk Writes/sec（用于测量物理 IO 操作，这是我的 SAN 团队关心的指标）。

类似于采样间隔的方法。我是在寻找一天还是一周的趋势？在这种情况下，我只会每 3-5 分钟采样一次，因为更频繁地采样我会尝试获得摆脱数据来制作可用的图表。我是否希望在问题发生时立即发现问题？那么我将每 15 秒到 1 分钟采样一次。

答案3

这些可能是有关选择性能计数器的 SQL Server MVP 建议的有用链接：

http://www.brentozar.com/archive/2006/12/dba-101-using-perfmon-for-sql-performance-tuning/

http://www.sql-server-performance.com/tips/sql_server_performance_monitor_coutners_p1.aspx

答案4

我更关心采样间隔而不是计数器的数量；如果您正在寻找基线或趋势，请不要使用 1 秒；如果您长期运行它，您最终会得到更多的数据，然后对其进行平滑分析。

相关内容