Анализ производительности Windows с использованием возможностей ОС и утилиты PAL

Автор статьи — Михаил Комаров, MVP — Cloud and Datacenter Management


В данной статье будут рассмотрены:

  • механизм работы со счетчиками производительности;
  • настройка сборщиков данных как с помощью графического интерфейса, так и с помощью командной строки;
  • создание черного ящика для записи данных.


Также рассмотрим и обсудим работу с утилитой PAL и ее применение для сбора и анализа данных, включая типовые проблемы локализованных систем.

В общем виде задачу о производительности можно представить в виде трех частей: сбор данных, анализ полученных данных и создание черного ящика для упреждающего мониторинга проблемной системы.


Начнем со всем давно известного Performance Monitor. Это стандартная утилита, которая входит во все современные редакции Windows. Вызывается либо из меню, либо из командной строки или строки поиска в Windows 8/10 вводом команды perfmon. После запуска утилиты мы видим стандартную панель, в которой можем добавить и удалить счетчики, изменить представление и масштабировать графики с данными.

b5427d4995e14a59af0a586e2f99f558.png

Также есть сборщики данных, с помощью которых производится сбор данных о производительности системы. При определённых навыках и сноровке операции по добавлению счетчиков и настройке параметров сбора данных можно производить из графического интерфейса. Но когда возникает задача настройки сбора данных с нескольких серверов, разумнее использовать утилиты командой строки. Вот этими утилитами мы и займемся.

Первая утилита — это Typeperf, которая может выводить данные со счетчиков производительности на экран или в файл, а также позволяет получить список счетчиков, установленных в системе. Примеры использования.

Выводит на экран загрузку процессора с интервалом 1 сек.:

typeperf "\Processor(_Total)\% Processor Time"

4676132634be489e8f5d2533ecf663cd.png

Выводит в файл названия счётчиков производительности, связанные с объектом PhysicalDisk:

typeperf -qx PhysicalDisk -o counters.txt

В нашем случае мы можем использовать утилиту Typeperf, чтобы создать файл с нужными нам счетчиками, который в дальнейшем будем использовать как шаблон для импорта счетчиков в сборщик данных.

Следующая утилита — Logman. Данная утилита позволяет создавать, изменять и управлять различными сборщиками данных. Мы будем создавать сборщик данных для счетчиков производительности. Вот, например, краткая справка по команде Logman, которая относится к счетчикам производительности и управлению сборщиком данных.

3306f4ac98be4d1dafc71ccafaa5c222.png
02be03abea2f443993d3d01ea676fb9b.png

Разберем несколько примеров, которые нам понадобятся в дальнейшем.

Создадим сборщик данных с именем DataCollector_test, импортировав счетчики производительности из файла test.xml:

logman import DataCollector_test -xml C:\PerfTest\test.xml

Создание файла для сбора данных производительности с включённым циркулярным режимом и заданным размером:

logman update DataCollector_test -f bincirc -max 600

Изменение пути файла с данными производительности по умолчанию:

logman update DataCollector_test -o C:\PerfTest\Test_log.blg

Запуск коллектора данных DataCollector_test:

logman start DataCollector_test

Остановка коллектора данных DataCollector_test:

logman stop DataCollector_test

Отметим, что все эти действия можно производить с удаленным компьютером.

Рассмотрим еще одну утилиту — Relog, которая позволяет производить манипуляции с файлом данных после работы сборщика данных. Вот ее описание:

440e74e64c844330894f0f2490506d5e.png

Ниже несколько сценариев применения этой утилиты.

Извлечение данных счетчиков производительности из файла logfile.blg с применением фильтра со списком счетчиков counters.txt и записью результата в бинарный формат:

relog logfile.blg -cf counters.txt -f bin

Извлечение списка счетчиков производительности из logfile.blg в текстовый файл counters.txt:

relog logfile.blg -q -o counters.txt

Напрямую работать с этой утилитой мы не будем, но информация о ней в дальнейшем поможет в случае возникновения проблем в файле PowerShell, который генерирует утилита PAL.

Отметим еще один момент, некоторые системы анализа требуют данные с наименованиями счетчиков производительности на английском языке. Если интерфейс нашей системы на русском языке, то нам необходимо проделать следующие манипуляции: завести локального пользователя, дать ему права на сбор данных (обычно дают права локального администратора), войти в систему под ним и в свойствах системы изменить язык интерфейса.

7497c539299a4439a6bec4ab883397d3.png

Обязательно выйти из системы и зайти во второй раз под этим пользователем для инициализации английского интерфейса и выйти из системы. Далее указать в сборщике данных, что сбор данных будет производиться от имени этого пользователя.

aff3b54f92594160a9fae1b13c13e5c1.png

После этого имена счетчиков и файлов будут на английском языке.

Также отметим возможность сбора данных для SQL Server с помощью утилиты из состава продукта. Это SQLDIAG, которая обрабатывает журналы производительности Windows, журналы событий Windows, трассировки SQL Server Profiler, сведения о блокировках SQL Server и сведения о конфигурации SQL Server. Указать, какие типы сведений нужно собирать с помощью программы SQLdiag, можно в файле конфигурации SQLDiag.xml.

2fa129fb073747dd80c91cd1afe80ca0.png

Для конфигурирования файла SQLDiag.xml можно использовать инструмент PSSDIAG с codeplex.com.

a355e15cd3dc42bba03ac19e23e258ef.png

Вот так выглядит окно этого инструмента.

852e60d5c3f347e79cd00db23f974304.png

В итоге, процесс сбора данных для SQL может выглядеть так. С помощью PSSDIAG мы формируем xml-файл. Далее посылаем этот файл клиенту, который запускает SQLDIAG c нашим xml-файлом на удаленном сервере и присылает нам для анализа результат работы в виде blg-файла, который мы будем анализировать в следующей части.


Данная утилита написана Clint Huffman, который является PFE-инженером Microsoft и занимается анализом производительности систем. Также он является одним из авторов авторизованного курса Vital Sign, который читается в Microsoft и доступен для корпоративных заказчиков, в том числе в России на русском языке. Утилита распространяется свободно, ссылку на нее я приведу ниже.

Вот так выглядит стартовое окно утилиты.

40250187bfce4485bf040ece8e74f563.png

На вкладке Counter Log задаётся путь к файлу данных со счетчиками производительности, собранными ранее. Также мы можем задать интервал, за который будет производиться анализ.

1db907652316444aa3a739512c605e2e.png

На вкладке Threshold File находится список шаблонов, которые можно экспортировать в формат xml и использовать как список счетчиков для сборщика данных. Обратите внимание на большой выбор шаблонов для анализа производительности для различных систем. Пример загрузки из командной строки был показан выше. Самое ценное, что в этих заранее подготовленных шаблонах установлены граничные значения для этих параметров, которые будут использованы в дальнейшем для анализа собранных данных!!!

f67df01dccc442b0accf44c59f3cacd2.png
d8fccb16d5374976a25512dc527e5cc8.png

Вот так, например, выглядят граничные значения для счётчиков дисковой производительности:

020c131185f444a1913a684868bce231.png

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

Действуем по следующему алгоритму: на рабочей станции запускаем утилиту PAL, переходим на вкладку Threshold File и экспортируем шаблон в виде xml-файла. На основании этого файла на сервере создаем сборщик данных и запускаем сборку информации.
После сбора данных копируем полученный файл на рабочую станцию, чтобы анализом не нагружать сервер, возвращаемся на вкладку Counter Log, указываем путь к файлу. Снова переходим на Threshold File и выбираем тот самый шаблон, который экспортировали для сборщика данных.

Переключаемся на вкладку Question и указываем объем оперативной памяти на сервере, на котором был осуществлён сбор данных. В случае 32-битной системы заполним UserVa.

36416c02a5f645ab9e69a2a9e7689a8d.png

Переходим к вкладке Output Options, на которой задаем интервал разбиения для анализа. Значение по умолчанию AUTO делит интервал на 30 равных частей.

d89495fc8edb411fb5de03b9595b80b7.png

Вкладка File Output выглядит довольно обычно, указываем на ней путь к файлам итоговых отчетов в формате HTML или XML.

f50b5fcec7144fcfad0e1cfc9eb47e75.png

Вкладка Queue показывает итоговый скрипт на PowerShell. В общем можно сказать, что утилита собирает параметры, которые она подставляет в скрипт PAL.PS1.

60027e4150bd407db0d9ee5872f61a89.png

Итоговая вкладка задает параметры исполнения. Можно одновременно запустить несколько скриптов и указать число потоков на процессоре. Хотелось бы акцентировать внимание, что обработку blg делает не утилита, а скрипт PowerShell, и это открывает возможности для полной автоматизации анализа логов. Например, каждые сутки перезапускается сборщик данных, в результате освобождается текущий blg-файл и создаётся новый. Старый файл копируется на специальный сервер, где будет запускаться скрипт, обрабатывающий данный файл. После этого готовый HTML- или XML-файл с результатами перемещается в определённую директорию или высылается на почтовый ящик.

04e1579e84aa4f8a89d31aba2ec1ea43.png

Обратите внимание, что утилита должна работать только в английской локализации. Иначе получим сообщение об ошибке.

5d499b684e4d44759ff9d705492fbb8d.png

Также файл с данными должен быть с названиями счетчиков на английском. Выше я указывал, как это сделать. После нажатия Finish запустится скрипт PowerShell, время работы которого зависит от объёма данных и быстродействия рабочей станции.

Итогом работы утилиты будет отчет в выбранном формате, в котором есть графики и числовые данные, позволяющие понять, что происходило в системе за заданный период с учетом граничных значений алертов в шаблоне на вкладке Threshold File. В общем, анализ HTML-файла позволит на начальном этапе определить проблемные места в системе и понять, куда двигаться дальше, как в плане более тонкого мониторинга, так и в плане модернизации или переконфигурирования системы. В блоге Clint Huffman есть скрипт, которым можно конвертировать файл шаблона с граничными условиями в более понятный формат.

af67caeaa97e49179869dd620055180a.png

519a311a0e094cd190b60248b8fd6d99.png


Иногда возникает необходимость в превентивном мониторинге проблемной системы. Для этого мы создадим «черный ящик», в который будем записывать данные производительности. Вернемся к скриптам, описанным ранее.

Создадим сборщик данных c именем BlackBox, импортировав счетчики производительности из файла SystemOverview.xml, который выгрузили из утилиты PAL или создали самостоятельно:

logman import BlackBox -xml C:\ BlackBox\SystemOverview.xml

Создание файла для сбора данных производительности с включённым циркулярным режимом и заданным размером 600 МБ (около 2 суток при стандартном наборе счетчиков):

logman update BlackBox -f bincirc -max 600

Изменение пути файла с данными производительности по умолчанию:

logman update BlackBox -o C:\ BlackBox \ BlackBox _log.blg

Запуск коллектора данных BlackBox:

logman start BlackBox

Данный скрипт создает задачу перезапуска сборщика данных в случае перезапуска системы:

schtasks /create /tn pal /sc onstart /tr "logman start BlackBox " /ru system

На всякий случай поправим свойства диспетчера данных, чтобы не заполнить место на диске, так как после перезапуска сборщика данных создается новый файл с лимитом 600 МБ.

99c571e6a8184137956d4e9ca61b70b7.png

Отметим, что скопировать файл с данными можно только при остановленном сборщике данных. Остановить же последний можно скриптом или с помощью графического интерфейса.

Остановка коллектора данных BlackBox:

logman stop BlackBox

На этом закончим часть, посвященную сбору и первичному анализу производительности.


Performance Monitor
https://technet.microsoft.com/en-us/library/cc749154.aspx

Утилита PAL
https://pal.codeplex.com/

Блог Clint Huffman
http://blogs.technet.com/b/clinth/

Книга Clint Huffman
Windows Performance Analysis Field Guide
http://www.amazon.com/dp/0124167012/ref=wl…=I2TOVTYHI6HDHC

© Habrahabr.ru