Назад | Перейти на главную страницу

Монитор производительности с 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

Если вы не собираете 1000 счетчиков каждую секунду, я не думаю, что вы увидите снижение производительности на сервере. Моя рекомендация: сосредоточьтесь на том, как вы собираетесь использовать их.

Я анализирую результаты трассировки в Excel, поэтому всегда сохраняю в формате CSV и проверяю, что захватываю менее 255 счетчиков (из-за ограничения столбцов в Excel).

Скорее всего, вам потребуется некоторое время, чтобы определить, какие счетчики вам полезны, но, как только вы это сделаете, захват дополнительных столбцов не принесет вам никакой пользы. Я, например, записывал все счетчики PhysicalDisk, пока не узнал, что наиболее полезными для меня были Avg Disk Sec / Read, Avg Disk Sec / Write (для измерения задержки) и Disk Reads / sec, Disk Writes / сек (для измерения физических операций ввода-вывода, которые важны для моей команды SAN).

Аналогичный подход к интервалу выборки. Я ищу дневные или недельные тренды? В этом случае я буду отбирать только каждые 3-5 минут, потому что чаще я буду пытаться получить избавляться данных, чтобы построить удобный график. Ищу ли я проблему в момент ее возникновения? Затем я буду производить выборку каждые 15 секунд - 1 минуту.

Это могут быть полезные ссылки на рекомендации 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

Я не могу назвать вам волшебное число, но могу сказать, что накладные расходы на счетчики производительности очень низкие. Информация уже есть, и Microsoft полностью рассчитана на то, чтобы вы использовали ее и собирали. Машине не нужно изо всех сил создавать их, все, что она делает, это захватывает их, вместо того, чтобы позволить им проскользнуть мимо, если вы решите добавить их. Я могу вам сказать, что у нас на производственной машине 75 штук, и мы не видим разницы в нагрузке.

Меня больше беспокоит интервал выборки, чем количество счетчиков; не используйте 1 секунду, если вы ищете исходные данные или тенденции; если вы работаете в долгосрочной перспективе, вы просто получаете больше данных, которые затем сглаживаете для анализа.