Трассировка событий

Назначение

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

Эта документация предназначена для приложений пользовательского режима, которые хотят использовать ETW. Сведения об инструментировании драйверов устройств, выполняемых в режиме ядра, см. в разделе Трассировка программного обеспечения WPP и Добавление трассировки событий для Kernel-Mode драйверов в наборе драйверов Windows (WDK).

Где применимо

Используйте ETW, если требуется инструментировать приложение, записывать события пользователя или ядра в файл журнала и использовать события из файла журнала или в режиме реального времени.

Аудитория разработчиков

Трассировка событий Windows разработана для разработчиков на C и C++, которые пишут приложения пользовательского режима.

Требования к среде выполнения

ETW входит в состав Microsoft Windows 2000 и более поздних версий. Сведения о том, какие операционные системы требуются для использования определенной функции, см. в разделе «требования» документации по функции.

Обработка трассировок трассировки событий Windows в коде .NET

Вы можете использовать API .NET трацепроцессинг для анализа трассировок трассировки событий Windows для приложений и других программных компонентов. Этот API внутренне используется в корпорации Майкрософт для анализа данных ETW, созданных в системе разработки Windows, а также для включения нескольких таблиц в анализаторе производительности Windows. Этот API доступен в виде пакета NuGet.

Цель «Средство трассировки событий для Windows» Event Tracing for Windows Target

Применимо к: Applies to: SQL Server SQL Server (все поддерживаемые версии) SQL Server SQL Server (all supported versions) База данных SQL Azure Azure SQL Database База данных SQL Azure Azure SQL Database Применимо к: Applies to: SQL Server SQL Server (все поддерживаемые версии) SQL Server SQL Server (all supported versions) База данных SQL Azure Azure SQL Database База данных SQL Azure Azure SQL Database

Прежде чем использовать средство трассировки событий для Windows (ETW) в качестве назначения, рекомендуется сначала попрактиковаться в работе с данным средством. Before you use Event Tracing for Windows (ETW) as a target, we recommend that you have a working knowledge of ETW. Трассировка событий Windows используется совместно с расширенными событиями или в качестве потребителя расширенных событий. ETW tracing is either used together with Extended Events or as an Extended Events event consumer. Следующие внешние ссылки помогут получить начальные сведения о трассировке событий Windows. The following external links provide a starting point for obtaining background information about ETW:

Цель «Трассировка событий Windows» является одноэлементным целевым объектом, хотя она может быть добавлена в несколько сеансов. The ETW target is a singleton target, although the target can be added to many sessions. Если событие происходит в нескольких сеансах, то данное событие будет передано цели трассировки событий Windows по одному разу для каждого произошедшего события. If an event is raised on many sessions, the event will only be propagated to the ETW target one time per event occurrence. Каждый процесс может иметь только одну подсистему расширенных событий. The Extended Events engine is limited to a single instance per process.

Чтобы назначение ETW работало, стартовая учетная запись служб SQL Server SQL Server должна входить в группу «Пользователи журналов производительности». For the ETW target to work, the SQL Server SQL Server Service startup account must be a member of the Performance Log Users group.

Конфигурация событий в сеансе ETW управляется процессом, в котором размещена подсистема расширенных событий. The configuration of the events present in an ETW session is controlled by the process that hosts the Extended Events engine. Эта подсистема управляет последовательностью и условиями запуска событий. The engine controls which events to raise and what conditions must be met for an event to occur.

После привязки к сеансу расширенных событий, который присоединяет назначение средства отслеживания событий для Windows в первый раз в процессе, средство ETW открывает один сеанс ETW в поставщике SQL Server SQL Server . After binding to an Extended Events session, which attaches the ETW target for the first time during the lifetime of a process, the ETW target opens a single ETW session on the SQL Server SQL Server provider. Если сеанс ETW уже существует, цель ETW получает ссылку на существующий сеанс. If an ETW session already exists, the ETW target obtains a reference to the existing session. Этот сеанс ETW используется всеми экземплярами SQL Server SQL Server на компьютере. This ETW session is shared across all SQL Server SQL Server instances on a given computer. Сеанс ETW получает все события от сеансов, имеющих цель ETW. This ETW session receives all the events from sessions that have the ETW target.

Поскольку приложению ETW требуются поставщики, способные потреблять события и направлять их в ETW, в сеансе включаются все пакеты расширенных событий. Because ETW needs providers to be enabled to consume events and flow them down to the ETW, all Extended Events packages are enabled on the session. При запуске события цель ETW отправляет его в сеанс, в котором включен поставщик события. When an event is fired, the ETW target sends the event to the session on which the provider for the event is enabled.

Назначение ETW поддерживает синхронную публикацию событий в потоке, запускающем это событие. The ETW target supports synchronous publishing of events on the thread that raises the event. Однако назначение ETW не поддерживает асинхронную публикацию событий. However, the ETW target does not support asynchronous event publishing.

Назначение трассировки событий Windows не может управляться внешними контроллерами трассировки событий Windows, например Logman.exe. The ETW target does not support control from external ETW controllers such as Logman.exe. Для трассировки событий Windows нужно создать сеанс события с назначением трассировки событий Windows. To produce ETW traces, an event session must be created with the ETW target. Дополнительные сведения см. в разделе CREATE EVENT SESSION (Transact-SQL). For more information, see CREATE EVENT SESSION (Transact-SQL).

При включении назначения ETW создается сеанс ETW с именем XE_DEFAULT_ETW_SESSION. Enabling the ETW target creates an ETW session that is named XE_DEFAULT_ETW_SESSION. Если сеанс с именем XE_DEFAULT_ETW_SESSION уже существует, то он используется как есть, без изменения свойств. If a session with the name XE_DEFAULT_ETW_SESSION already exists, it is used without modifying any properties of the existing session. Сеанс XE_DEFAULT_ETW_SESSION используется совместно всеми экземплярами SQL Server SQL Server . The XE_DEFAULT_ETW_SESSION is shared between all instances of SQL Server SQL Server . После запуска сеанса XE_DEFAULT_ETW_SESSION необходимо остановить его с помощью контроллера ETW, например инструмента Logman. After you start the XE_DEFAULT_ETW_SESSION, you must stop it by using an ETW controller, such as the Logman tool. Например, можно выполнить в командной строке следующую команду: logman stop XE_DEFAULT_ETW_SESSION -ets. For example, you can run the following command at the command prompt: logman stop XE_DEFAULT_ETW_SESSION -ets.

В следующей таблице описаны доступные параметры для настройки назначения ETW. The following table describes the available options for configuring the ETW target.

Параметр Option	Допустимые значения Allowed values	Описание Description
default_xe_session_name default_xe_session_name	Любая строка длиной до 256 символов. Any string up to 256 characters. Это значение является необязательным. This value is optional.	Имя сеанса расширенных событий. The Extended Events session name. По умолчанию это XE_DEFAULT_ETW_SESSION. By default, this is XE_DEFAULT_ETW_SESSION.
default_etw_session_logfile_path default_etw_session_logfile_path	Любая строка длиной до 256 символов. Any string up to 256 characters. Это значение является необязательным. This value is optional.	Путь к файлу журнала сеанса расширенных событий. The path of the log file for the Extended Events session. По умолчанию %TEMP%\ XEEtw.etl. By default, this is %TEMP%\ XEEtw.etl.
default_etw_session_logfile_size_mb default_etw_session_logfile_size_mb	Любое целое число без знака. Any unsigned integer. Это значение является необязательным. This value is optional.	Размер файла журнала для сеанса расширенных событий (в мегабайтах, МБ). The log file size, in megabytes (MB), for the Extended Events session. По умолчанию установлено значение 20 МБ. The default is 20 MB.
default_etw_session_buffer_size_kb default_etw_session_buffer_size_kb	Любое целое число без знака. Any unsigned integer. Это значение является необязательным. This value is optional.	Размер буфера в памяти (в килобайтах) для сеанса расширенных событий. The in-memory buffer size, in kilobytes (KB), for the Extended Events session. Значение по умолчанию — 128 КБ. The default is 128 KB.
retries retries	Любое целое число без знака. Any unsigned integer.	Число попыток публикации события в подсистеме ETW до удаления события. The number of times to retry publishing the event to the ETW subsystem before dropping the event. Значение по умолчанию равно 0. The default is 0.

Конфигурация указанных параметров не обязательна. Configuring these settings is optional. Цель ETW использует для них параметры по умолчанию. The ETW target uses default values for these settings.

Цель ETW отвечает за следующие действия. The ETW target is responsible for:

Создание сеанса ETW по умолчанию. Creating the default ETW session.

Регистрация всех пакетов расширенных событий в приложении ETW. Registering all Extended Events packages with ETW. Тем самым обеспечивается сохранность событий в приложении ETW. This ensures that events are not dropped by ETW.

Управление потоком событий, направляемых приложению ETW. Managing the flow of events to ETW. Цель ETW создает событие ETW с данными, полученными от расширенных событий, и отправляет это событие в соответствующий сеанс ETW. The ETW target creates an ETW event with Extended Events data and sends it to the appropriate ETW session. Если событие превышает размер буфера или данные не вмещаются в одно событие ETW, приложение ETW разбивает это событие на фрагменты. If the event is larger than the buffer size, or data cannot fit in one ETW event, ETW splits the event into fragments.

Хранение пакетов расширенных событий включено постоянно. Keeping Extended Events packages enabled at all times.

Приложение ETW по умолчанию использует следующие расположения. The following default file locations are used by ETW:

Выходной файл ETW: %TEMP%\XEEtw.etl. The ETW output file is in %TEMP%\XEEtw.etl.

После начала первого сеанса путь к файлу изменить нельзя. The file path cannot be changed after the first session starts.

MOF-файлы находятся в папке: \Microsoft SQL Server\Shared Managed Object Format (MOF) files are in \Microsoft SQL Server\Shared. Дополнительные сведения см. в разделе Формат управляющих объектов библиотеки MSDN. For more information, see Managed Object Format on MSDN.

Добавление цели к сеансу Adding the Target to a Session

Для добавления назначения счетчика событий в сеанс расширенных событий следует использовать одну из следующих инструкций при создании или изменении сеанса события: To add the ETW target to an Extended Events session, you must include the following statement when you create or alter an event session:

Дополнительные сведения о полном примере, который показывает, как использовать назначение трассировки событий, включая просмотр данных, см. в разделе отслеживать активность системы с помощью расширенных событий. For more information about a full example that shows how to use the ETW target, including how to view the data, see Monitor System Activity Using Extended Events.

Механизм трассировки событий для Windows

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

Одним из богатейших источников информации является провайдер ядра (kernel provider), который генерирует события в моменты запуска процессов и потоков, загрузки DLL, распределения блоков памяти, сетевых операций ввода/вывода и при выполнении трассировки стека. В таблице ниже приводится перечень некоторых наиболее интересных событий, сообщаемых ETW-провайдерами ядра и CLR. Механизм ETW можно использовать для исследования общего поведения системы, например, чтобы выяснить, какой из процессов потребляет большую часть вычислительной мощности CPU, проанализировать узкие места в операциях ввода/вывода, получить статистику, касающуюся работы сборщика мусора и использования памяти управляемыми процессами, и во многих других случаях, обсуждаемых далее.

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

Неполный список событий ETW в ядре Windows и CLR

Запуск и завершение процессов и потоков

Загрузка и выгрузка образов (библиотек DLL, драйверов, выполняемых файлов)

Дисковые операции чтения и записи

Ошибки обращения к страницам диска (которые были вытеснены из кеша в оперативной памяти)

Дискретное событие — сохранение информации о состоянии стека для всех процессоров выполняется через каждую 1 мсек

Статистика и информация о работе механизма сборки мусора

Запуск сборки, конец сборки, запуск процедур завершения, выделение блока памяти — 100 Кбайт

Конфликт между потоками выполнения при попытке приобрести разделяемую блокировку

Начало конфликта (поток переведен в режим ожидания), конец конфликта

Информация о состоянии динамического компилятора (Just in Time, JIT)

Успешная попытка встраивания метода, неудачная попытка встраивания метода

Для доступа к этой детализированной информации требуется специализированный инструмент и приложение, способное читать события ETW и выполнять простейший анализ. На момент написания этих строк существовало два инструмента, способных решать обе задачи: Windows Performance Toolkit (WPT, также известный как XPerf), распространяемый в составе Windows SDK, и PerfMonitor (не путайте с Windows Performance Monitor!) — открытый проект, разрабатываемый командой CLR в Microsoft.

Windows Performance Toolkit (WPT)

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

Чтобы установить WPT, загрузите дистрибутив Windows SDK, запустите мастер установки и выберите только Windows Performance Toolkit (Общие утилиты —> Windows Performance Toolkit):

Если вы устанавливаете WPT в Windows 7, то после установки Windows SDK перейдите в подкаталог Redist\Window Performance Toolkit в каталоге установки SDK и запустите мастер установки для своей аппаратной архитектуры (Xperf_x86.msi — для 32-разрядных систем, Xperf_x64.msi — для 64-разрядных систем). Для Windows 8 эти шаги делать не нужно.

В 64-разрядной версии Windows для поддержки возможности трассировки стека необходимо изменить настройки в реестре, запрещающие выгрузку страниц с кодом из оперативной памяти в файл подкачки (для самого ядра Windows и для всех драйверов). Это может увеличить потребление оперативной памяти системой на несколько мегабайт. Чтобы изменить настройки, найдите в реестре ключ HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management, установите параметр DisablePagingExecutive типа DWORD в значение 0x1 и перезагрузите систему.

Для перехвата и анализа событий ETW используются инструменты XPerf.exe и XPerfView.exe. Оба должны запускаться с привилегиями администратора. Утилита XPerf.exe имеет несколько ключей командной строки, с помощью которых можно указать, какие провайдеры должны включаться, размеры используемых буферов, имя файла для сохранения информации о событиях и множество других параметров. Утилита XPerfView.exe анализирует исходную информацию и генерирует графические отчеты на основе информации в файле журнала.

Вместе с событиями может сохраняться также информация о состоянии стека вызовов, что часто помогает выявить дополнительные грани проблем производительности. Однако, чтобы получить информацию о состоянии стека совсем необязательно включать прием событий от какого-то определенного провайдера — флаг sysProfile позволяет получать эту информацию от всех процессоров с интервалом 1 мсек. Это упрощенный способ понять суть событий, протекающих в системе на уровне методов.

Захват и анализ событий ядра с помощью XPerf

В этом разделе предлагается выполнить трассировку событий ядра с помощью XPerf.exe и проанализировать полученные результаты с помощью XPerfView.exe. Данный эксперимент планировался для проведения в версии Windows Vista или выше. (Для его проведения требуется также настроить две системные переменные окружения: откройте панель управления и перейдите в меню «Система», щелкните на пункте «Дополнительные параметры системы» в панели слева и в открывшемся диалоге — на кнопке «Переменные среды» внизу.) Проделайте следующие шаги:

Создайте системную переменную окружения _NT_SYMBOL_PATH со значением, включающим путь к общедоступному серверу символов и локальному кешу символов, например: srv*C:\Temp\Symbols*http://msdl.microsoft.com/download/symbols.

Создайте системную переменную окружения _NT_SYMCACHE_PATH со значением, включающим путь к локальному каталогу на диске — это должен быть другой каталог, отличный от того, что был указан в качестве локального кеша символов в предыдущем пункте.

Запустите с правами администратора командную строку и перейдите в каталог установки WPT (например, C:\Program Files\Windows Kits\8.1\Windows Performance Toolkit).

Запустите прием событий из группы Base ядра, содержащие флаги из таблицы выше. Для этого выполните команду: xperf -on Base.

Сымитируйте некоторую активность в системе: запустите несколько приложений, попереключайтесь между окнами, попробуйте открыть какие-нибудь файлы — хотя бы несколько секунд. (Все это будет приводить к созданию отслеживаемых событий.)

Остановите прием событий и сохраните результаты в файл, выполнив команду: xperf -d KernelTrace.etl.

Запустите инструмент анализа, выполнив команду: xperfview KernelTrace.etl («wpa KernelTrace.etl» — для Windows SDK 8.0 и выше)

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

Щелкните правой кнопкой мыши на графике нагрузки на процессор и выберите пункт контекстного меню Load Symbols (Загрузить символы). Щелкните правой кнопкой мыши на графике еще раз и выберите пункт контекстного меню Simple Summary Table (Простая сводная таблица). В результате должна появиться таблица со списком методов во всех процессах, проявлявших активность в процессе сбора информации. (Загрузка символов с сервера Microsoft в первый раз может занять продолжительное время.)

Последняя версия Windows SDK (8.0 — 8.1) включает два новых инструмента: Windows Performance Recorder (wpr.exe) и Windows Performance Analyzer (wpa.exe), созданные с целью постепенно заменить инструменты XPerf и XPerfView, описанные выше. Например, команда wpr -start CPU является примерным эквивалентом команды xperf -on Diag, а команда wpr -stop reportfile — примерным эквивалентом команды xperf -d reportfile. Пользовательский интерфейс инструмента WPA несколько отличается, но предоставляет практически те же возможности, что и XPerfView. За дополнительной информацией по новым инструментам обращайтесь по адресу: «What’s New in the WPT».

Инструмент WPT способен на большее, чем было показано в этом эксперименте. Вам следует заняться самостоятельными исследованиями пользовательского интерфейса и попробовать принять и проанализировать другие группы событий ядра или даже события от собственных провайдеров ETW. (Создание собственных провайдеров рассматривается далее.)

Инструмент WPT может пригодиться в самых ситуациях, поможет вникнуть в поведение системы и отдельных процессов. Ниже представлено несколько скриншотов и описаний примеров подобных ситуаций:

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

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

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

WPT может отображать сводную информацию о состоянии стеков вызовов (когда утилита приема событий запускалась с ключом -stackwalk) — это дает возможность получить полную информацию о стеках вызовов на момент создания определенных событий.

Инструмент XPerfView (или WPA) обладает достаточно широкими возможностями в отображении данных, поставляемых провайдером ядра, в виде удобных графиков и таблиц, но он не обладает столь же широкой поддержкой других провайдеров. Например, мы можем обеспечить трассировку событий от провайдера CLR ETW, но XPerfView не будет создавать графики для различных событий — нам придется самим разбираться в исходных данных трассировки, опираясь на список ключевых слов и событий, перечисленных в документации (полный перечень ключевых слов и событий провайдера CLR ETW).

Если запустить XPerf с провайдером CLR ETW для сбора событий с ключевым словом GCKeyword (0x00000001) и уровнем детализации verbose (0x5), эта утилита послушно будет перехватывать все события, генерируемые провайдером. Сохранив всю полученную информацию в файл CSV или открыв ее с помощью XPerfView, мы сможем (хотя и с трудом) идентифицировать события механизма сборки мусора в нашем приложении.

На рисунке ниже показан пример отчета, созданного утилитой XPerfView, где время между событиями GC /start и GC /stop соответствует протяженности одного цикла работы механизма сборки мусора:

Выделенная строка на этом рисунке — это событие GCAllocationTick_V1, генерируемое после распределения каждых 100 Кбайт памяти. К счастью, этот недостаток был замечен разработчиками базовой библиотеки классов (Base Class Library, BCL) в Microsoft, и они создали открытую библиотеку и инструмент PerfMonitor для анализа трассировочной информации от CLR ETW. Мы рассмотрим этот инструмент далее.

PerfMonitor

— это открытый инструмент командной строки, созданный командой разработчиков BCL в Microsoft, и доступный на сайте CodePlex. На момент написания этих строк самой последней была версия PerfMonitor 2.01. Главное преимущество PerfMonitor перед WPT заключается в полной поддержке событий CLR и способности выводить информацию о них не только в табличном виде. PerfMonitor способен анализировать события, генерируемые сборщиком мусора и JIT-компилятором, выполнять трассировку управляемого стека и определять нагрузку на процессор, оказываемую различными частями приложения.

Для опытных пользователей в состав PerfMonitor включена библиотека с именем TraceEvent, обеспечивающая программный доступ к событиям CLR ETW и позволяющая автоматизировать анализ событий. Библиотеку TraceEvent можно использовать в собственных приложениях мониторинга для автоматического исследования и регистрации событий, протекающих в ходе эксплуатации системы.

Инструмент PerfMonitor можно использовать для сбора событий ядра или даже событий собственного провайдера ETW (запуская его с ключами /KernelEvents И /Provider), но обычно он применяется для анализа поведения управляемых приложений с использованием встроенных провайдеров CLR. С помощью ключа runAnalyze ему молено указать любое приложение для трассировки, по завершении которого PerfMonitor сгенерирует подробный отчет в формате HTML и откроет его в браузере по умолчанию. (Чтобы создать отчеты, похожие на те, что представлены в этой статье, вам следует ознакомиться с руководством для PerfMonitor — хотя бы с разделом «Quick Start». Для этого выполните команду PerfMonitor usersguide.)

Чтобы произвести запуск PerfMonitor с целью выполнить приложение и сгенерировать отчет, нужно использовать следующую команду (в процессе чтения этой статьи вы можете сами поэкспериментировать с инструментом, запуская с его помощью приложение JackCompiler.exe из папки с исходниками):

Различные HTML-файлы отчетов, сгенерированные инструментом PerfMonitor, содержат уже обработанную информацию, но вы всегда можете открыть исходные ETL-файлы с помощью XPerfView или любого другого инструмента, способного читать двоичные файлы журналов с событиями ETW. Сводный отчет для примера выше включает следующую информацию (при выполнении эксперимента на вашем компьютере фактические значения могут отличаться):

статистика использования CPU — на выполнение приложения было потрачено 917 мсек процессорного времени, а средняя нагрузка составила 56.6%. Остальное время было потрачено на ожидание каких-то событий;

статистика сборщика мусора — общее время работы сборщика мусора составило 20 мсек, максимальный размер кучи сборщика мусора составил 4.5 Мбайт, максимальная скорость выделения памяти составила 1496.1 Мбайт/сек, а средняя пауза между циклами сборки мусора составила 0.1 мсек.

статистика JIT-компилятора — за время выполнения JIT-компилятором было скомпилировано 159 методов с общим объемом машинного кода 30493 байт.

Погружаясь на более глубокие уровни отчетов можно получить огромное количество полезной информации. В число детальных отчетов использования CPU входят: отчет о методах, на выполнение которых было потрачено больше всего процессорного времени (восходящий анализ), отчет о деревьях вызовов, где было потрачено больше всего процессорного времени (нисходящий анализ), и отдельные отчеты «вызывающий-вызываемый» для каждого метода. Чтобы предотвратить разбухание отчетов, из них исключается информация со значениями ниже определенного порога (1% — для восходящего анализа, и 5% — для нисходящего анализа).

На рисунке ниже представлен пример отчета восходящего анализа, где видно, что тремя наиболее активно используемыми методами являются System.String.Concat(), JackCompiler.Tokenizer.Advance() и System.Linq.Enumerable.Contains():

Здесь колонка «Exc %» — оценка процессорного времени, затраченного только на выполнение данного метода; колонка «Inc %» — оценка процессорного времени, затраченного на выполнение данного метода и всех других методов, которые он вызывает (его поддерево вызовов).

На рисунке ниже представлен пример отчета нисходящего анализа, где видно, что 84.2% процессорного времени было потрачено методом JackCompiler.Parser.Parse(), который вызывает методы ParseClass(), ParseSubDecls(), ParseSubDecl(), ParseSubBody() и так далее:

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

Наконец, отчет о работе JIT-компилятора содержит информацию о времени, затраченном на компиляцию каждого из методов приложения, а также точное время, когда они были скомпилированы. Эта информация может пригодиться, чтобы выяснить, можно ли увеличить скорость запуска приложения — если на этапе запуска приложения значительное время тратится на работу JIT-компилятора, предварительная компиляция приложения (с помощью NGen) может оказаться существенной оптимизацией. Применение NGen и другие стратегии уменьшения времени запуска приложения мы обсудим в одной из следующих статей.

В ходе сбора информации от нескольких провайдеров ETW могут получаться очень большие файлы журналов. Например, в режиме по умолчанию PertMonitor генерирует примерно 5 Мбайт данных в секунду. Если оставить инструмент работать на несколько дней, он наверняка исчерпает дисковое пространство даже на очень большом жестком диске. К счастью, оба инструмента, XPerf и PerfMonitor, поддерживают циклический режим журналирования, когда в журнале сохраняется только последние N Мбайт данных. В PerfMonitor максимальный размер файла журнала можно указать (в мегабайтах) с помощью ключа /Circular, при этом все старые файлы будут автоматически удаляться при превышении указанного порогового значения.

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

PerfView

— бесплатный инструмент, разрабатываемый в корпорации Microsoft, объединяющий в себе функции сбора информации от провайдеров ETW и ее анализа, по аналогии с PerfMonitor, а также средства анализа динамической памяти, которые будут обсуждаться в следующей статье, во время знакомства с такими инструментами, как CLR Profiler и ANTS Memory Profiler. Загрузить PerfView можно по адресу: PerfView. Обратите внимание, что инструмент PerfView должен запускаться с привилегиями администратора, потому что требует доступа к инфраструктуре ETW.

Чтобы проанализировать информацию, полученную при выполнении определенного процесса, выберите пункт меню Collect —> Run в PerfView (на рисунке ниже показано главное окно программы).

В панели со списком файлов (слева) можно видеть дамп динамической памяти и файл с информацией ETW. Ссылки в центральной области окна ведут к разным командам, поддерживаемым инструментом.

Для нужд анализа распределения динамической памяти, который мы вскоре выполним, в исходниках к этой статье включено приложение MemoryLeak.exe. Это приложение будет запускаться с помощью инструмента PerfView, который сгенерирует отчеты со всей информацией, доступной в PerfMonitor, и не только, включая:

простой список событий ETW, полученных от разных провайдеров (например, с информацией о конфликтах в CLR, дисковых операциях ввода/вывода, TCP-пакетах и ошибках чтения страниц);

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

участки стека вызовов, соответствующие операциям загрузки образов (сборок), дисковым операциям ввода/вывода и операциям выделения памяти (для каждых 100 Кбайт);

статистика сборщика мусора, включая продолжительность каждого цикла сборки мусора и объем освобожденной памяти.

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

На рисунке ниже изображен пример анализа ссылок на объекты класса Schedule, которые занимают в динамической памяти 31 Мбайт. PerfView благополучно обнаружил, что ссылки на объекты Schedule хранятся в экземплярах класса Employee, а экземпляры Employee удерживаются в памяти очередью объектов, готовых к завершению.

Собственные провайдеры ETW

Как и при использовании счетчиков производительности, у вас может появиться желание внедрить в свое приложение поддержку возможности сбора и передачи информации, предлагаемой инфраструктурой ETW.

До появления версии .NET 4.5, экспортирование информации ETW из управляемых приложений было весьма непростым делом. Необходимо было учитывать массу тонкостей, связанных с определением манифеста провайдера ETW для вашего приложения, созданием его во время выполнения и регистрацией событий. С выходом .NET 4.5, создание собственных провайдеров ETW стало легче некуда. Для этого достаточно унаследовать класс от EventSource из пространства имен System.Diagnostics.Tracing, и вызвать метод WriteEvent() базового класса для вывода событий ETW. Все рутинные операции по регистрации провайдера в системе и форматированию информации в событиях выполняются автоматически.

Ниже приводится пример реализации провайдера ETW в управляемом приложении:

Для получения информации из такого приложения можно использовать инструмент PerfMonitor. Запустить с его помощью приложение, произвести сбор

Существует еще один инструмент мониторинга производительности и состояния систем, который еще не упоминался: . WMI — инфраструктура контроля и управления (command-and-control, C&C), интегрированная в Windows, но ее рассмотрение далеко выходит за рамки этой статьи. Ее можно использовать для получения информации о состоянии системы (например, о версии установленной системы, версии программного обеспечения BIOS или о свободном пространстве на диске), регистрации интересующих событий (таких как запуск и завершение процессов) и вызова управляющих методов, изменяющих состояние системы (таких как создание сетевых разделяемых ресурсов или выгрузка драйверов).

Провайдер	Флаг/ключевое слово	Описание	События
Ядро	PROC_THREAD