Данный материал является переводом статей MSSQLTips "Joe Gavin : Windows Performance Monitor Counters for SQL Server" и "Joe Gavin : SQL Server Disk Related Performance Monitor Counters".
В данной статье, мы узнаем о том, как получить данные о производительности и интерпретировать результаты некоторых часто используемых счетчиков Windows Performance Monitor (Perfmon), связанных с SQL Server.
В прошлый раз мы смотрели, как создать и запустить Perfmon Data Collector Set для сбора информации о производительности в режиме реального времени. Теперь мы рассмотрим некоторые выходные данные, показатели и значения, на которые следует обращать внимание в контексте решения проблем в работе SQL Server.
Объекты и Счетчики Perfmon
В следующей таблице приведен список объектов Perfmon и счетчиков производительности, которые обычно используются для проверки производительности SQL Server, а также их описания и руководство по ожидаемым значениям.
|
Perfmon Объект |
Счетчик |
Описание Счетчика |
Рекомендации |
|
Memory |
Available MBytes |
Доступные мегабайты — это объем физической памяти в |
Должно оставаться довольно постоянным и, вероятно, не опускаться ниже 4096 МБ или около того. Может указывать, что "максимальная память сервера" оставлена по умолчанию, приложения, отличные от SQL Server, работают на сервере. |
|
Processor
|
% Processor Time
|
% процессорного времени — это процент истекшего времени, которое процессор (ЦП) тратит на выполнение потока, отличного от простоя. |
% процессорного времени будет сильно различаться на активном сервере. Всплески до |
|
Physical Disk |
Avg. Disk sec/Read |
Среднее время в секундах чтения данных с диска |
В идеале должен быть менее 15 миллисекунд. Оно не должно превышать 50 миллисекунд. |
|
Physical Disk |
Avg. Disk sec/Write |
Среднее время в секундах записи данных на диск |
В идеале должен быть менее 15 миллисекунд. Оно не должно превышать 50 миллисекунд. |
|
Physical Disk |
Disk Reads/sec |
Скорость операций чтения на диске |
В идеале должен быть менее 15 миллисекунд. Оно не должно превышать 50 миллисекунд. |
|
Physical Disk |
Disk Writes/sec |
Скорость операций записи на диск |
В идеале должен быть менее 15 миллисекунд. Оно не должно превышать 50 миллисекунд. |
|
SQLServer:Access Methods |
Forwarded Records/sec |
Количество записей, полученных с помощью перенаправленных указателей записей |
В идеале близко к 0. |
|
SQLServer:Access Methods |
Full scans/sec |
Количество неограниченных полных сканирований. Это может быть сканирование базовой таблицы или полное сканирование индекса. |
Предпочтительно менее 1. |
|
SQLServer:Access Methods |
Page Splits / Sec |
Количество разбиений страниц в секунду, возникающих в |
Должно быть меньше 20% всех Batch Requests/Sec. |
|
SQLServer:Buffer Manage |
Buffer Cache hit ratio |
Процент страниц, которые были найдены в пуле буферов без чтения с диска |
Вы хотели бы, чтобы это значение было постоянным или близким к 100%. Меньше может |
|
SQLServer:Buffer Manager |
Checkpoint Pages / Sec |
Количество страниц, сброшенных контрольной точкой или |
Ориентир для сравнения. |
|
SQLServer:Buffer Manager |
Page life expectancy |
Количество секунд, в течение которых страница будет оставаться в пуле буферов без ссылок. |
Эмпирическое правило: это не должно опускаться ниже 300 миллисекунд. |
|
SQLServer:General Statistics |
User Connections |
Количество пользователей, подключенных к системе. |
Используется в качестве эталонного значения, чтобы увидеть, увеличивается ли среднее число со временем, что указывает на большую активность. |
|
SQLServer:Locks |
Average |
Среднее время ожидания (в миллисекундах) для каждого запроса на блокировку, который привел к ожиданию. |
В идеале должно быть 0. |
|
SQLServer:Locks |
Lock Waits / Sec |
Количество запросов на блокировку, которые не могли быть удовлетворены немедленно и требовали от вызывающего объекта ожидания перед предоставлением блокировки. |
В идеале должно быть 0. |
|
SQLServer:Memory Manager |
Memory |
Текущее количество процессов, ожидающих предоставления памяти рабочей области |
В идеале должно быть 0. |
|
SQLServer:Memory Manager |
Target Server Memory (KB) |
Идеальный объем памяти, который сервер готов потреблять |
Соотношение: Общая память сервера (КБ) / память целевого сервера (КБ) должна быть приблизительно равна 1. |
|
SQLServer:Memory Manager |
Total Server Memory (KB) |
Общий объем динамической памяти, потребляемой сервером в данный момент. |
Соотношение: Общая память сервера (КБ) / память целевого сервера (КБ) должна быть |
|
SQLServer:SQL Statistics |
Batch Requests/Sec |
Количество пакетных запросов SQL, полученных сервером |
Бенчмарк активности сервера. |
|
SQLServer:SQL Statistics |
SQL |
Количество компиляций SQL |
Должен быть на уровне 10% или меньше от общего Batch Requests/sec. |
|
SQLServer:SQL Statistics |
SQL Re-Compilations/Sec |
Количество перекомпиляций SQL |
Должен быть на уровне 10% или меньше от общего Batch Requests/sec. |
Просмотр данных о производительности
В консоли Performance Monitor переходим к нашему ранее созданному и запущенному Data Collector Set.
- Щелчок ПКМ на Collector Set;
- Выбираем пункт меню "Latest Report".
Здесь мы видим данные, собранные в определенный день с 11:45 до 12:45. Верхняя часть экрана представляет собой графическое представление каждого счетчика. Прямо под ним находятся значения для выбранного счетчика. А внизу мы можем включит или отключить отображение того или иного счётчика.
На примере счётчиков работы дисковой подсистемы, представленных ниже, среднее значение чтения с диска в секунду для диска D: составляет 0,048 секунды = 48 миллисекунд. Это приближается к верхнему пределу в 50 миллисекунд и указывает на низкую производительность диска на этом сервере, что требует дальнейшего изучения. Я запускаю это на виртуальной машине с Windows Server 2019, размещенной на ноутбуке, поэтому не ожидаю большой производительности. Если бы это был настоящий сервер, пора было бы обсудить это с командой поддержки системы хранения данных.
Для того, чтобы увидеть более чистое графическое представление мы можем оставить лишь отображение интересующих нас счётчиков. Например, ниже мы сняли все флажки в столбце "Show", кроме "% Processor Time", чтобы показать видеть график только по процессорному времени. Глядя на числа внизу, мы видим, что минимум был 0%, максимум 55,746%, а средний 0,289%. Как видим, около 12:35 был очень короткий всплеск, но в остальном показатель был низким.
Для рассмотрения ещё одного примера, давайте обратимся к таблице Perfmon Object / Counter и увидим, что для того, чтобы выяснить, является ли "SQL Compilations/Sec" и "SQL Re-Compilations/sec" ниже порога, необходимого для получения значения "Batch Requests/sec".
- Оставим только три счетчика в запросе;
- Щелчок ПКМ в области Counters;
- Выберем каждый из трёх счетчиков индивидуально;
- Выберем масштаб, который соответствует линии в области экрана в раскрывающемся списке для "Batch Requests/sec" и подходит к "SQL Compilations/Sec" и "SQL Re-Compilations/sec";
- Нажмём "OK"
Глядя на график, мы видим, что "Batch Requests/sec" единственный хорошо видимый счетчик. "SQL Compilations/sec" и "SQL Re-Compilations/sec" едва видны на дне. На глаз это указывает, что они оба значительно ниже порога 10%.
Для подтверждения выберите "Average Batch Requests/sec" и это 0.065. 10% от 0.065 будет 0.0065. Выберите "SQL Compilations/Sec" и среднее 0.001. Выберите "SQL Re-Compilations/Sec" и среднее 0.00. Оба этих значения меньше 0.0065, так что в нашем случае работа SQL Server в допустимых рамках.
Экспорт данных Perfmon в файл CSV
Вы можете предпочесть просматривать и анализировать данные Perfmon в электронной таблице. Perfmon дает нам возможность экспортировать данные в файл формата CSV.
- Щелкните ПКМ на любом из счётчиков;
- Выберите пункт "Save Data As…".
- Выберите каталог сохранения;
- Задайте имя файла;
- Выберите тип 'Text File (Comma delimited)(.csv)' в выпадающем списке;
- Нажмите "Save".
После некоторого форматирования, чтобы сделать его более читабельным, и сохранения в формате .xlsx, данные готовы к дальнейшему анализу в Microsoft Excel.
RSS - Записи
Добавить комментарий