Подсистема Event Tracing for Windows (ETW) представляет собой мощное средство диагностики и тестирования производительности. По замыслу специалистов Microsoft, ETW должен был стать механизмом, с помощью которого программисты могли бы оценить влияние своих приложений на платформы Windows Server 2003, Windows XP и Windows 2000. Однако ETW можно использовать и для того, чтобы следить за событиями, происходящими внутри систем Windows, приложений Microsoft (например, Microsoft IIS) и приложений независимых поставщиков, и диагностировать любые обнаруженные неполадки. Кроме того, администраторам проще планировать ресурсы, используя ETW для мониторинга системы, работающей с реальной нагрузкой, при выполнении конкретного набора транзакций. Но прежде чем приступить к рассказу об инструментах и методах ETW и привести практический пример, хочу познакомить читателей с архитектурой ETW.

Архитектура ETW

Зачем разработчики Microsoft предложили еще один способ сбора данных о производительности, если существует Performance Monitor? Прикладным программистам и администраторам нужен был инструмент с малым потреблением ресурсов, обеспечивающий контроль приложений и процессов в рабочей среде без существенного снижения скорости системы. Трудно избежать заметного падения быстродействия, если на производственных серверах круглосуточно работает программа мониторинга. Но именно такую цель преследовали специалисты Microsoft, проектируя ETW. Для этого используется архитектура, в которой объединены компоненты режимов ядра и пользователя, оптимизированные для быстрой записи событий в журнал или прикладное приложение.

Как показано на рис. 1, архитектура ETW состоит из нескольких компонентов: трассировщика событий, журнала или прикладного приложения, провайдеров и программы контроллера. Трассировщик событий создает сеансы протоколирования режима ядра или пользователя, во время которых выполняется собственно трассировка. Windows 2003 и XP поддерживают до 62 сеансов протоколирования, а Windows 2000 — до 31. Каждый сеанс располагает специальным пулом буферов, в которые трассировщик событий записывает данные. Windows создает буферы для каждого процессора, поэтому если приложение инициирует событие на процессоре 0, то трассировщик записывает это событие в буфер трассировки данного процессора. Администратор может указать минимальное и максимальное число буферов, создаваемых Windows для данного сеанса протоколирования. По умолчанию Windows создает буферы в пуле памяти, не подлежащей страничному обмену с диском, и не переписывает информацию о событиях на диск, если в системе не хватает памяти. Благодаря этой мере повышается скорость протоколирования, так как в нужный момент буферы всегда находятся в памяти. Однако режим протоколирования можно изменить, и буферы будут размещаться в пуле страничной памяти.

Трассировщик событий отмечает время каждого события. В метке времени приводится следующая информация:

  • время события;
  • ID процесса, в котором совершилось событие;
  • ID потока, в котором совершилось событие;
  • время работы процессора в пользовательском режиме;
  • время работы процессора в режиме ядра.

При организации сеанса трассировки можно задать точность замера времени. Разрешение может составлять от 100 мс до 100 нс, в зависимости от механизма, используемого трассировщиком для определения времени. Чем ниже разрешение, тем меньше влияние трассировщика на общую производительность системы. Однако время событий будет указываться с меньшей точностью.

После заполнения буфера трассировщик переписывает данные в журнал или прикладное приложение. Если прикладное приложение требует протоколирования в реальном времени, то трассировщик записывает данные о событиях в приложение почти в реальном времени. При записи 20 000 событий в минуту на типичной системе ETW использует примерно 5% ресурсов процессора. События записываются в специальном двоичном файле с расширением .etl. Эти двоичные файлы не предназначены для чтения пользователем, но с помощью инструментов, о которых рассказывается ниже, их можно преобразовать в текстовые, HTML- или CSV- файлы.

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

В Windows 2003, XP и Windows 2000 имеются готовые провайдеры для различных системных служб, в том числе Active Directory (AD), Lightweight Directory Access Protocol (LDAP), Internet Information Services (IIS) 6.0, ASP.NET, Netlogon и Local Security Authority (LSA). Кроме того, компания Microsoft предоставляет встроенный провайдер ядра Windows для операций системного уровня, таких как создание и уничтожение процессов, создание и уничтожение потоков, дисковый ввод/вывод, файловый ввод/вывод, трафик TCP и UDP, страничные сбои, регистровый ввод/вывод, загрузка образов исполняемых файлов и контекстные переключатели. В данной статье основное внимание уделяется встроенным провайдерам. Можно подготовить и собственных провайдеров. Для этого следует изучить документацию по трассировщику событий, опубликованную в Microsoft Developer Network (MSDN) по адресу http://msdn.microsoft.com/library/en-us/perfmon/base/event_tracing.asp.

Приложение-контроллер создает сеансы протоколирования, устанавливает начальные параметры (в частности, размеры буферов, разрешение временных меток) и запускает и останавливает сеансы протоколирования в соответствии с расписанием. Компания Microsoft предлагает несколько готовых приложений-контроллеров, которые рассмотрены в разделе «Инструменты ETW».

Главная особенность архитектуры ETW заключается в том, что каждый компонент (например, трассировщик событий, приложение-контроллер) работает независимо. Провайдеру не требуется информации о трассировщике событий, приложению-контроллеру не нужна информация о провайдере и т. д. В такой архитектуре не составляет труда задействовать генерируемые ETW-данные для различных целей. Кроме того, ETW предоставляет специалистам по прикладному программированию превосходную инфраструктуру для тестирования влияния приложений на системы Windows, избавляя их от необходимости самостоятельно строить функции протоколирования.

Инструменты ETW

В Windows 2003, XP и Windows 2000 существует два способа создавать отчеты о сеансах ETW и управлять ими: можно использовать оснастку Performance Logs and Alerts консоли управления Microsoft Management Console (MMC) или утилиты командной строки. В Windows 2003 и XP имеются утилиты командной строки. В Windows 2000 утилиты командной строки являются составной частью набора ресурсов Microsoft Windows 2000 Server Resource Kit, они слегка отличаются от утилит Windows 2003 и XP. В контексте архитектуры ETW оснастка Performance Logs and Alerts и некоторые утилиты командной строки представляют собой приложения-контроллеры. Другие утилиты командной строки обеспечивают функционирование прикладного приложения.

Инструменты XP в основном такие же, как и в Windows 2003, но в XP меньше готовых провайдеров. Поэтому, хотя далее в статье речь идет только об инструментах Windows 2003, все сказанное относится и к XP.

Оснастка Performance Logs and Alerts

Если запустить оснастку Performance Logs and Alerts и перейти к узлу Trace Logs, то можно создать новый сеанс трассировки, щелкнув на узле правой кнопкой мыши и выбрав New Log Settings. После того как новому сеансу протоколирования будет присвоено имя, на экране появится диалоговое окно Properties. На вкладке General можно выбрать провайдеров. Чтобы объем данных не оказался чрезмерно большим, рекомендуется ограничить число провайдеров в одном сеансе. Например, если нужно регистрировать события ядра и AD, то следует создать два отдельных сеанса протоколирования. Анализировать большие массивы данных трассировки чрезвычайно сложно. При необходимости впоследствии можно объединить отчеты, полученные в ходе сеансов двух провайдеров, с помощью инструментов Microsoft.

На вкладке General можно активизировать трассировку параметров, предоставляемых провайдером ядра Windows (системным провайдером) или несистемным провайдером, зарегистрированным в системе. Например, с помощью провайдера ядра Windows можно активизировать трассировку сети TCP/IP (экран 1). Чтобы активизировать трассировку с помощью несистемных провайдеров, следует перейти в режим Nonsystem providers, затем щелкнуть на кнопке Add и выбрать провайдеров. Щелкнув на кнопке Provider Status, можно узнать, какие провайдеры зарегистрированы в текущей системе. Наконец, и Windows 2003, и XP располагают функцией Run As, которая позволяет запустить трассировщик под именем пользователя, отличным от того, под которым пользователь зарегистрирован в данный момент.

Экран 1. Использование провайдера ядра Windows для трассировки TCP/IP

На вкладке Log Files можно изменить схему именования журнала и способ записи данных в журнал трассировщиком событий. Существует два способа протоколирования: последовательный и циклический. В последовательном режиме трассировщик событий записывает данные до тех пор, пока журнал не достигнет максимального размера, определенного администратором. Если максимальный размер не указан, то трассировщик событий будет продолжать запись до тех пор, пока диск не заполнится или администратор не завершит сеанс протоколирования. В циклическом режиме трассировщик событий перезаписывает данные после того, как размер журнала достигает указанной максимальной величины.

Вкладка Schedule используется для задания времени начала и конца сеанса протоколирования. Сеанс можно запустить и остановить вручную из пользовательского интерфейса оснастки Performance Logs and Alerts. Независимо от того, был ли сеанс запущен по расписанию или вручную, для записи данных трассировки в журнал используется служба Windows — Performance Logs and Alerts. Эта служба запускается от имени учетной записи Administrator или обладающей равноценными полномочиями, поэтому пользователю необходимо зарегистрироваться с такой учетной записью (в Windows 2003 служба доступна и членам встроенной группы Performance Logs). В противном случае сеанс трассировки запустить не удастся.

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

На вкладке Advanced можно изменить стандартные параметры выделения буферов трассировщика событий. Можно указать как иной размер буфера, так и минимальное и максимальное число выделяемых буферов. Как правило, при настройке этих параметров приходится выбирать между регистрацией событий без пропусков и экономией системной памяти. Для регистрации большого количества событий, например файлового или регистрового ввода/вывода, обычно используется от 50 до 100 буферов размером 128 Кбайт, но на практике полезно поэкспериментировать с выбором параметров.

Утилиты командной строки

Существует несколько вариантов запуска сеанса трассировки из командной строки, которые, к сожалению, различаются в зависимости от версии операционной системы. В набор ресурсов Windows 2000 входит утилита tracelog.exe, с помощью которой можно создавать сеансы трассировки для провайдера ядра Windows и управлять ими. В наборе ресурсов нет утилиты командной строки для создания и управления сеансами трассировки несистемных провайдеров.

С помощью Tracelog.exe можно организовать временный сеанс записи данных трассировки. Если tracelog.exe используется для временного сеанса записи данных трассировки, то этот сеанс не будет отражен в интерфейсе пользователя оснастки Performance Logs and Alerts.

Чтобы активизировать трассировку TCP/IP на системе Windows 2000 с помощью tracelog.exe, следует ввести команду:

tracelog -start -noprocess -nothread
-nodisk -b 128 -min 50 -max 100
-f c:perflogs
etfile.etl

Команда напечатана на нескольких строках, но на экране ее следует вводить одной строкой. То же самое относится и к другим многострочным командам, упоминаемым в данной статье. Команда Tracelog -start создает временный сеанс протоколирования. При создании сеанса трассировки командой tracelog.exe по умолчанию активизируются четыре типа трассировки: создания и уничтожения процессов, создания и уничтожения потоков, сети TCP/IP и дискового ввода/вывода. Поскольку нужна лишь трассировка TCP/IP, в командной строке указаны параметры -noprocess, -nothread и -nodisk, чтобы отключить соответственно режимы трассировки создания и уничтожения процессов, создания и уничтожения потоков и дискового ввода/вывода. Параметр -b устанавливает размер буфера 128 Кбайт, а параметры -min и -max определяют минимальное и максимальное число выделяемых буферов. Благодаря параметру -f программа tracelog.exe выводит двоичные данные в файл netfile.etl в папке perflogs. Следует обратить внимание, что команда Tracelog -start в одно действие создает и запускает сеанс протоколирования. Чтобы остановить протоколирование, достаточно ввести команду

tracelog -stop

В Windows 2003 появилась усовершенствованная утилита командной строки logman.exe, с помощью которой можно управлять сеансами трассировки. В отличие от tracelog.exe, logman.exe позволяет задействовать несистемных провайдеров. К сожалению, на системах Windows 2000 logman.exe не работает. Logman.exe располагает несколькими полезными функциями, в том числе возможностью подготовки списка зарегистрированных в системе провайдеров. Чтобы вызвать эту функцию, следует ввести команду

logman query providers

На основании информации из полученного списка можно активизировать провайдера для конкретного сеанса протоколирования. Предположим, что с помощью logman.exe требуется активизировать трассировку AD на системе Windows 2003. Получив с помощью команды Logman query имя нужного провайдера (в данном случае Active Directory: Core), необходимо создать сеанс протоколирования. Число параметров командной строки logman.exe огромно. Чтобы не усложнять командную строку и принять все стандартные параметры, можно создать сеанс протоколирования AD с помощью команды

logman create trace AD_trace
-o c:perflogs
-p «Active Directory: Core»

В результате выполнения данной команды logman.exe создает новый сеанс протоколирования с именем AD_trace. Перед именем сеанса необходим ключ trace, так как с помощью logman.exe можно создавать также сеансы Performance Monitor, которые генерируют журналы другого типа. Параметр -o указывает, что выходной двоичный файл будет помещен в папку perflogs. Параметр -p указывает имя провайдера, который следует использовать. Можно указать имя или глобально уникальный идентификатор (GUID) провайдера.

Для запуска сеанса протоколирования следует ввести команду

logman start AD_trace

При использовании logman.exe для создания сеанса протоколирования трассировки сеанс отображается в пользовательском интерфейсе оснастки Performance Logs and Alerts. Из интерфейса можно изменить, запустить и остановить сеанс.

Методы анализа данных

Зная, как собрать данные трассировки событий, можно рассмотреть способы преобразования этих данных в удобную для восприятия информацию. Компания Microsoft выпустила две утилиты командной строки для преобразования двоичных файлов .etl в удобный формат. В наборе ресурсов Windows 2000 имеется утилита tracedmp.exe, с помощью которой можно преобразовать один или несколько файлов .etl в файл .csv. Этот файл можно открыть в Microsoft Excel или другой электронной таблице для дальнейшего анализа. Windows 2003 и XP располагают утилитой командной строки tracerpt.exe. И tracedmp.exe, и tracerpt.exe — прикладные приложения в рамках архитектуры ETW. Хотя tracerpt.exe является составной частью Windows 2003 и XP, эту утилиту можно использовать для обработки журналов Windows 2000. Tracerpt.exe располагает рядом функций, отсутствующих в tracedmp.exe, поэтому я рекомендую для работы с журналом трассировки Windows 2000 всегда использовать tracerpt.exe. Однако tracerpt.exe нельзя отдельно загрузить с сайта Microsoft. Получить утилиту можно, только купив Windows 2003 или XP.

Следует обратить внимание, что если запустить tracerpt.exe с рабочей станции Windows 2003 или XP для обработки журнала, созданного на сервере Windows 2000, то tracerpt.exe не всегда может идентифицировать GUID транзакций на сервере Windows 2000. Чтобы определить события, которым соответствует конкретный GUID транзакции, tracerpt.exe обращается к пространству имен Windows Management Instrumentation (WMI) на той системе, на которой утилита была запущена. Если система, на которой был создан отчет, не располагает теми же провайдерами трассировки событий, что и система, на которой запущена трассировка, то tracerpt.exe не может получить информацию о событиях, необходимую для подготовки файлов отчетов. Таким образом, при обработке утилитой tracerpt.exe файла журнала, созданного на сервере Windows 2000, собирающего информацию AD, я рекомендую запускать tracerpt.exe с контроллера домена (DC) Windows 2003, который также располагает провайдерами AD, зарегистрированными в WMI.

И tracedmp.exe, и tracerpt.exe преобразуют двоичный файл .etl в файл .csv. Кроме того, обе утилиты выдают текстовый файл, содержащий итоговую информацию о сеансе протоколирования (например, продолжительность сеанса) и зарегистрированных событиях (имя, тип и число повторений события, а также GUID провайдера, создавшего событие). Однако tracedmp.exe создает итоговый отчет автоматически, а в tracerpt.exe предусмотрен ручной режим. С помощью tracerpt.exe также можно составить отчет о рабочей нагрузке. В этом отчете приведена сводная информация о процессах и транзакциях, которые отслеживались в ходе сеанса протоколирования. Например, при мониторинге активности процессов в отчете о рабочей нагрузке будут приведены суммарные данные обо всех работавших процессах, времени загрузки процессора каждым процессом и числе потоков, используемых каждым процессом.

Чтобы задействовать tracerpt.exe для генерации файла .csv, итогового отчета и отчета о рабочей нагрузке, следует ввести команду

tracerpt myfirstlog.etl mysecondlog.etl
-o -summary -report

где myfirstlog.etl и mysecondlog.etl — имена .etl-файлов, которые требуется преобразовать. После каждого из параметров -o, -summary и -report можно указать имя файла. Если имя не указано, то по умолчанию будут созданы файлы dumpfile.csv для детального файла .csv (параметр -o), summary.txt для итогового отчета (параметр -summary) и workload.txt — для отчета о рабочей нагрузке. Если имеется несколько исходных .etl-файлов, как в приведенном выше примере, то данные объединяются в файле .csv, итоговом и рабочем отчетах. Возможность объединить отчеты полезна, если требуется сопоставить данные из разных сеансов трассировки с одинаковыми интервалами времени. Версия tracerpt.exe, поставляемая в составе Windows 2003, обеспечивает изменение формата итогового отчета и отчета о рабочей нагрузке. Можно генерировать текстовые, XML- и HTML-файлы.

Основной продукт сеанса протоколирования — .csv-файл. В нем перечислены все события, произошедшие во время сеанса, время их совершения и продолжительность обработки события процессором в режимах ядра и пользователя. Кроме того, в .csv-файле хранятся все данные, связанные с транзакцией. Например, при сетевой трассировке ядра Windows будут получены следующие данные: событие TCP или UDP Send или Receive (показывает IP-адрес и порт источника и назначения) и число переданных и принятых байтов. Для удобства чтения .csv-файлы можно импортировать в Excel, но на практике сеансы трассировки генерируют очень большие массивы данных. Поэтому, чтобы получить из них полезную информацию, нужен специальный подход. Рассмотрим, как можно использовать ETW на практике.

Применение трассировки событий

Цель трассировки событий — сбор данных о среде, которые могут послужить базой для дальнейших действий. Например, администратору необходимо ввести в AD большое число пользователей и он не уверен, достаточны ли имеющиеся аппаратные ресурсы Windows 2003 DC для обработки возросшего трафика аутентификации. Выполнив трассировку событий, можно получить ясную картину текущей рабочей нагрузки при аутентификации на сервере и определить требования к ресурсам каждого события входа в систему. Затем на основании этой информации можно определить, какую нагрузку создадут дополнительные пользователи.

Трассировку можно организовать двумя способами. Первый подход — назначить начало сеанса трассировки AD на время массовой регистрации пользователей в рабочей среде и собирать данные достаточно долго, чтобы определить влияние каждого события регистрации на DC. Второй подход — провести трассировку в контролируемой лабораторной среде, чтобы определить среднюю нагрузку, создаваемую одной транзакцией при регистрации, а затем экстраполировать среднюю нагрузку на число пользователей, обслуживаемых системой. Запуск сеанса трассировки AD в рабочей среде отразится на DC. Хотя нагрузка сеанса на процессор, скорее всего, составит менее 5%, но многим администраторам не удастся запустить сеанс трассировки в своей рабочей среде. Поэтому следует рассмотреть лабораторный подход более подробно.

Чтобы запустить сеанс трассировки AD в лабораторной среде, можно воспользоваться оснасткой Performance Logs and Alerts для организации двух сеансов протоколирования на Windows 2003 DC. Один сеанс протоколирования будет задействовать несистемных провайдеров, представляющих рабочую нагрузку AD на DC во время регистрации пользователя. Во втором сеансе для сбора статистики ядра будет применяться системный провайдер. Благодаря дополнительным данным ядра удается генерировать точный и полный отчет о рабочей нагрузке.

Чтобы организовать первый сеанс, следует выбрать в оснастке режим Nonsystem providers и добавить всех провайдеров, связанных с AD (Active Directory: Kerberos, Active Directory: Netlogon, Active Directory: SAM, Local Security Authority, NTLM Security Protocol и Windows NT Active Directory Service). Чтобы организовать второй сеанс, нужно выбрать режим Events logged by system provider и установить как минимум флажки Process creations/deletions, Thread creations/deletions, Disk input/output и Network TCP/IP.

После того как будут назначены два сеанса протоколирования трассировки, нужно вручную запустить каждый сеанс, затем зарегистрироваться в AD на системе Windows 2003. После завершения процедуры регистрации оба сеанса протоколирования нужно остановить. Затем следует объединить два полученных .etl-файла с помощью tracerpt.exe и генерировать файл CSV, итоговый отчет и отчет о рабочей нагрузке.

Изучив типичный .csv-файл, можно обнаружить множество различных событий. Эти события представляют транзакции, закодированные разработчиками Microsoft в провайдерах, а события соответствуют набору выполняемых действий. Как видно по тестовой записи .csv (см. рис. 2), разобраться в таких событиях непросто.

Первая строка .csv-файла содержит заголовок, который идентифицирует каждое поле данных. Например, тестовая запись на рис. 2 содержит семь полей данных.

  • Event Name — указывает имя события. В данном случае имя события — GetASTicket, запрос клиента к службе Kerberos Authentication Service.
  • Type — указывает тип события. Как правило, в этом поле содержатся записи Start или End, которые отмечают соответственно начало и конец события.
  • TID — содержит список ID-потока (в шестнадцатеричном формате), в котором происходит текущее событие.
  • Clock-Time — указывает, когда произошло событие. Время представлено в формате Integer8 — 64-разрядная величина содержит число 100-нс интервалов, прошедших после 12:00 дня 1 января 1601 года. Несмотря на сложность формата Integer8, компания Microsoft часто использует его в службах, таких как WMI и AD.
  • Kernel (мс) — указывает время работы процессора в режиме ядра для данного события, измеренное в тактовых импульсах. Тактовые импульсы преобразуются в реальное время с учетом тактовой частоты типичного компьютера, период для которого составляет 10 мс. Например, 100 тактовых импульсов соответствуют 1 секунде (100*10 мс). Следует отметить, что время работы процессора, представленное в этой записи, и время пользовательского режима могут ввести в заблуждение, так как указывается время от запуска потока до того, как трассировщик событий инициирует событие. Таким образом, при генерации данных о времени работы придется полагаться на отчет о рабочей нагрузке.
  • User (мс) — указывает время работы процессора в режиме пользователя для данного события, измеренное в тактовых импульсах.
  • User Data — содержит любые ассоциированные данные, приведенные Microsoft для этой транзакции. В данном случае Microsoft предоставила четыре дополнительных фрагмента информации. Первое значение, 0x00000025, — флажок идентификатора экземпляра, который не имеет отношения к теме данной статьи. Второе значение, administrator, указывает ID пользователя, запросившего службу аутентификации, а третье значение, krbtgt/DOMAINA, — имя службы выделения билетов Kerberos, работающей в домене с именем DOMAINA. Последнее значение, DOMAINA, — имя домена назначения.

Разобраться в информации о событиях не всегда легко. К сожалению, компания Microsoft не документировала данные, выдаваемые AD и соответствующими провайдерами. Однако все провайдеры трассировки событий зарегистрированы в пространстве имен WMI. Поэтому можно использовать такие инструменты, как WMI CIM Studio, для поиска транзакций каждого провайдера и полей данных в этих транзакциях. WMI CIM Studio можно загрузить из Microsoft Download Center (http://www.microsoft.com/downloads/details. aspx?displaylang=en&familyid=6430f853-1120-48db-8cc5-f2abdc3ed314). Зарегистрированных провайдеров можно найти на пути rootWMIEventTrace.

На экране 2 показана информация для транзакции GetASTicket, выданная программой WMI CIM Studio. В WMI CIM Studio транзакции рассматриваются как классы, а поля данных — как свойства. Имена свойств WMI не точно соответствуют заголовкам полей данных в файле .csv, но достаточно похожи, чтобы человек мог определить поля данных в файле .csv.

Экран 2. Информация из WMI о несистемных зарегистрированных провайдерах

Чтобы не работать с «сырыми» данными файла .csv, можно воспользоваться отчетом о рабочей нагрузке. На экране 3 показан отчет о рабочей нагрузке, который утилита tracerpt.exe генерирует из данных, полученных при трассировке процедуры регистрации AD. При подготовке этого отчета tracerpt.exe преобразует «сырые» данные файла .csv в удобную для восприятия статистику, в частности указывает общее число транзакций. Например, для подсчета общего числа транзакций GetASTicket события Start и End в «сырых» данных .csv объединяются в пары. Затем tracerpt.exe подсчитывает число пар.

Экран 3. HTML-отчет трассировки нагрузки при регистрации пользователей в AD

Еще один статистический показатель в отчете о рабочей нагрузке — Response Time (мс), который отражает общее время, потраченное на транзакцию. Если время отклика равно 0, значит, отчет не отформатирован для показа нужного числа знаков после запятой. Поэтому весьма малое число (например, 0,00023) округляется до 0.

Отчет о рабочей нагрузке (см. экран 3) содержит данные о транзакциях 14 различных типов, которые проводились в процессе регистрации пользователя. Для совершения каждой из этих транзакций требуется некоторое время и расходуется время процессора. Кроме того, некоторые транзакции проводятся не один раз. В файле .csv содержится информация о времени, прошедшем от начала до конца транзакции, и числе тактов, необходимом для каждой транзакции. Таким образом, с помощью информации из обоих отчетов можно подсчитать общее время загрузки процессора и определить нагрузку на DC для одного сеанса регистрации пользователя. Например, импортировав .csv-файл в Excel, можно провести сортировку по имени транзакции и сложить время работы процессора в режимах ядра и пользователя для каждой пары start-end, чтобы получить общее время загрузки процессора для каждого типа транзакции. Такой метод позволяет получить более детализированные данные, чем статистика в отчете о рабочей нагрузке.

Следует помнить о том, что рассматриваются только AD и связанные с ней подсистемы, такие как Kerberos и процесс LSA. Другие события процедуры регистрации, такие как загрузка из сети профиля пользователя и сбор информации Group Policy, не учитываются. При необходимости можно использовать некоторых других провайдеров для сбора данных об этих событиях. Например, с помощью провайдера Windows Kernel можно собрать статистику файлового ввода/вывода.

Кроме того, следует помнить, что для определения общей нагрузки нельзя просто умножить нагрузку, генерируемую одним пользователем при регистрации на DC, на общее число пользователей. Как правило, нагрузка растет нелинейно, так как на AD и другие транзакции влияют такие процессы, как кэширование памяти. Поэтому, чтобы получить ясное представление о нагрузке при увеличении числа пользователей, следует повторить тест трассировки нагрузки, инкрементируя число пользователей. Таким образом можно выяснить, как общая нагрузка на процессор зависит от числа пользователей.

Эффективность трассировки событий

Трассировка обеспечивает богатые возможности для сбора информации о событиях, происходящих в системе Windows, и о количестве ресурсов, необходимом для выполнения данной операции. С помощью ETW можно проанализировать функционирование внутренних механизмов систем и приложений в лабораторной и рабочих средах, что не позволяет сделать Performance Monitor.

Даррен Мар-Элиа — редактор журнала Windows & NET Magazine. С ним можно связаться по адресу: dmarelia@winnetmag.net