Модернизация приложений
Часть 8. Измерение производительности системы и приложений. Утилита XPerf
Windows Performance Toolkit: базовые сведения
Основы использования утилиты XPerf
Получение информации о системе
В предыдущих частях данной статьи мы познакомились с техникой, позволяющей избежать утечек памяти, предотвратить зависание приложений, обсудили использование механизмов Application Restart and Recovery и Windows Error Reporting, а также узнали о возможностях утилиты Application Verifier.
В этой и последующих частях мы рассмотрим, как проводить анализ производительности системы и приложений с помощью средств, включенных в состав Windows Performance Toolkit. Эти средства позволяют получить детальную информацию об использовании ресурсов системы — процессора, диска, памяти, сети и т.п., которую можно применять для выявления проблем с повышенной утилизацией ресурсов, их «утечками», задержками в реакции системы, сервисов, процессов и приложений на системные запросы и проблемы, влияющие на эффективное использование подсистемы питания.
Windows Performance Toolkit доступен на клиентских и серверных операционных системах — Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2 — и поддерживается для платформ x86, x64 и ia64. Набор утилит Windows Performance Toolkit распространяется в составе Windows SDK — после установки SDK из каталога BIN необходимо установить версию Windows Performance Toolkit, подходящую для вашей платформы, — wpt_x86.msi, wpt_x64.msi или wpt_ia64.msi соответственно.
Дополнительную информацию по Windows Performance Toolkit можно получить на сайте, посвященном производительности, — он располагается адресу: http://msdn.microsoft.com/en-us/performance/default.aspx.
Windows Performance Toolkit: базовые сведения
В основе Windows Performance Toolkit лежат две утилиты: XPerf, которая служит для активации сбора информации, и XPerfView, используемая для визуального анализа информации о производительности. Взаимодействие XPerf и XPerfView с системными компонентами — в первую очередь с подсистемой Event Tracing for Windows (ETW) — показано на рис. 1.
Рис. 1. Взаимодействие утилит XPerf и XPerfView с системными компонентами
В общем случае работа с утилитами XPerf и XPerfView происходит следующим образом:
- с помощью утилиты XPerf включаем протоколирование событий на уровне ETW;
- выполняем интересующие нас операции, процессы и т.п.;
- с помощью утилиты XPerf завершаем сессию протоколирования;
- выполняем обработку информации — добавление к ETL-файлу, создаваемому подсистемой ETW, системной информации и символов;
- просматриваем и анализируем результат с помощью утилиты XPerfView (рис. 1).
Основы использования утилиты XPerf
Базовые операции по сбору информации используют подсистему протоколирования событий на уровне ядра операционной системы. Для того чтобы узнать, какие провайдеры (поставщики информации) доступны для данной версии операционной системы, можно выполнить следующую команду (здесь и далее применяется интерфейс командной строки с повышенными привилегиями: при вызове CMD. EXE необходимо нажать правую кнопку мыши и выполнить команду Run as Administrator):
C:\>xperf –providers
Сокращенный результат выполнения данной команды показан на рис. 2.
Рис. 2. Получение списка провайдеров
Как видно из рис. 2, операционная система предоставляет большое число (порядка тысячи) провайдеров информации для различных подсистем, использование которых позволяет собирать и анализировать различные аспекты работы как самой системы, так и процессов и приложений, выполняемых под ее управлением.
Для получения списка провайдеров информации только на уровне ядра (Kernel Mode Providers) можно выполнить следующую команду:
C:\>xperf –providers K
Результат выполнения данной команды показан на рис. 3.
Рис. 3. Получение списка Kernel Mode Providers
Флаги (Kernel Flags) отвечают за сбор информации об отдельных группах операций — например создание и удаление процессов, операции вводавывода и т.п. Группы (Kernel Groups) включают комбинации флагов и используются для анализа работы определенных подсистем. Для нашего первого эксперимента с утилитой XPerf мы выберем группу DiagEasy, которая содержит следующие флаги:
PROC_THREAD+LOADER+DISK_IO+HARD_FAULTS+DPC+INTERRUPT+CSWITCH+PERF_COUNTER
Описание этих флагов показано в таблице.
Выполним следующую команду для протоколирования событий на уровне ETW:
C:\>xperf –on DiagEasy
Эта команда начинает сбор данных в файл с именем “\kernel.etl”, который по умолчанию располагается в корне диска С:\. Можно изменить имя файла с помощью опции -f <filename> — это необходимо, например, при анализе операций вводавывода, чтобы создание и заполнение файла трассировки не вносило дополнительных помех (в таком случае нужно указать другой диск для хранения создаваемого файла). Подсистема протоколирования использует буфер с размером по умолчанию 64 Кбайт — минимально применяется 64 буфера, максимальное число одновременно используемых буферов — 320.
Запустим, например, Internet Explorer и откроем в нем какойнибудь сайт. После этого завершим протоколирование с помощью команды:
C:\>xperf –d trace.etl
Выполнение данной команды займет некоторое время (порядка 1-2 мин), так как системе требуется объединить данные, собранные ETW, с метаданными и другой информацией и сформировать соответствующий файл — в нашем примере это trace.etl. Теперь выполним команду:
C:\>xperf trace.etl
В результате откроется окно Windows Performance Analyzer — утилиты для визуального анализа результатов, собранных с помощью утилиты XPerf. Аналогичный результат можно получить, выполнив команду:
C:\>xperfview trace.etl
Утилита Windows Performance Analyzer графически отображает собранную информацию в виде ряда экранов: CPU Usage by Process, Disk I/O, Disk Utilization, Process Lifetimes, DPC CPU Usage, Interrupt CPU Usage, Hard Faults, Generic Events и других, включением или отключением которых можно управлять из меню (рис. 4).
Рис. 4. Графический анализ информации
Выбор типов графиков осуществляется с помощью всплывающего меню Frame List, которое вызывается при нажатии кнопки в левой части экрана.
Если мы хотим получить информацию только по интересующему нас процессу, то на графике CPU Usage by Process необходимо выбрать кнопку Processes (в правой части графика) и процесс — в нашем примере это IEXPLORE.EXE.
Так мы получим график загрузки центрального процессора только интересующим нас приложением. Мы можем выбирать временные интервалы, увеличивать отдельные области графика, накладывать на него дополнительную информацию и т.п. (рис. 5).
Рис. 5. График загрузки центрального процессора
Отметим, что для каждого графика доступна таблица с суммарной информацией (щелкнуть правой кнопкой мыши на графике и выбрать команду Summary Table), содержащая числовую информацию, на основе которой был построен тот или иной график.
Давайте обсудим, что мы узнали из приведенного выше примера:
- сбор данных о событиях уровня ядра можно включать и отключать в любое время. Нет необходимости в перезагрузке системы, повторном подключении к ней, перезапуске процессов и т.п. — события уровня ядра, а также любые ETW-события могут использоваться динамически, по мере необходимости;
- в отличие от утилит, которые динамически отображают состояние системы, XPerf служит для сбора информации о событиях, произошедших на определенном отрезке времени, и ее последующего анализа;
- возможность сбора данных для их последующего анализа позволяет собирать данные на одном компьютере, а анализировать их — на другом, например в тестовой лаборатории или для сбора данных на Windows XP и их анализа на Windows Vista или Windows 7; это необходимо, так как обработка результатов не поддерживается в Windows XP;
XPerf позволяет собирать данные об активности на уровне как всей системы, так и отдельных процессов.
Получение информации о системе
Как мы уже отметили, часто информация, собранная на одном компьютере, анализируется на другом. Для получения информации о конфигурации системы нужно использовать следующую команду:
C:\> xperf –i trace.etl –a sysconfig
Вывод будет произведен в консоль. Если необходимо сохранить данные в файле, выполняется операция перенаправления вывода:
C:\> xperf –i trace.etl –a sysconfig >c:\analysis\sysconfig.txt
Пример фрагмента отображаемой информации показан на рис. 6.
Рис. 6. Получение информации о конфигурации системы
Используя Windows Performance Analyzer, информацию о конфигурации системы можно получить с помощью команды Trace → System Configuration (рис. 7).
Рис. 7. Информация о конфигурации системы
XPerf и визуализация стека
Одна из возможностей, чрезвычайно полезных при анализе работы приложений и их отладке, — это так называемая визуализация стека. Отметим, что эта функциональность не требует никаких изменений в коде. Всё, что необходимо, — это отладочные символы для анализируемых бинарных компонентов. Визуализация стека, декодирование символов и возможность сбора данных на любой системе без перезапуска процессов или самой операционной системы делают Windows Performance Analyzer удобным средством для диагностики широкого класса проблем, связанных с производительностью.
Для того чтобы воспользоваться функцией визуализации стека, необходимо загрузить отладочные символы для операционной системы (PDB-файлы), на которой проводится сбор информации о приложениях, процессах и т.п. Их можно либо загрузить с сайта по адресу: http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx и самостоятельно установить на локальном компьютере (по умолчанию символы устанавливаются в каталог c:\windows\symbols), либо использовать онлайновую загрузку со специального сервера компании Microsoft. И в том, и в другом случае необходимо указать местоположение отладочных символов с помощью переменной среды _NT_SYMBOL_PATH. Вот пример команды, устанавливающей значение этой переменной (команда должна быть введена одной строкой):
C:\>set _NT_SYMBOL_PATH=
srv*C:\symbols*http://msdl.microsoft.com/downloads/symbols
Адрес сайта, указанный в приведенной выше команде, — это «сервер символов» компании Microsoft. Адрес локальной папки, помещенный между символами «*», указывает на локальное хранилище символов, куда будут помещены загруженные с сервера символы.
При анализе собственных приложений также необходимо указать местоположение PDB-файлов для конкретного приложения. Адрес локальной/удаленной папки добавляется к приведенной выше команде set через разделитель «;»:
C:\>set _NT_SYMBOL_PATH=
srv*C:\symbols*http://msdl.microsoft.com/downloads/symbols;
c:\Products\Versions\1.0\
После того как мы научились загружать символы и указывать их местоположение, давайте посмотрим на визуализацию стека в действии. Для этого выполним следующую команду (команда должна быть введена одной строкой):
C:\>xperf –on PROC_THREAD+LOADER+INTERRUPT+DPC+PROFILE
–stackwalk profile
Затем запустим интересующее нас приложение, выполним в нем необходимые операции и завершим сессию сбора информации командой:
C:\>xperf –d test.etl
После этого, как и в предыдущем примере, запустим Windows Performance Analyzer для визуального анализа собранной информации:
C:\>xperf test.etl
Визуализация стека включается на графике CPU Sampling by Process. Первая операция — это выполнение команды Load Symbols (в случае загрузки символьной информации с сервера выполнение этой команды может занять некоторое время), затем — команды Summary Table. В отдельном окне будут показаны результаты вызова функций — в данной версии XPerf поддерживается до 16 уровней вложенности.
Обратите внимание на возможность просмотра внутренних и внешних вызовов для каждой функции: после выбора интересующей функции необходимо нажать правую кнопку мыши и выбрать команду Callers или Callees и соответственно команду Innermost или Outermost. Данные для каждой команды будут отображены в отдельном окне, что удобно при анализе цепочек вызова внутри или вне определенной группы функций — как ядра операционной системы, так и анализируемого приложения.
Колонка %Weight указывает вызовы функций, на которые приходилось больше всего времени из всего времени работы данного процесса или приложения. Это более информативно, чем статическое профилирование с указанием времени работы каждой функции, так как в данном случае мы видим еще и цепочку вызовов функций (рис. 8).
Рис. 8. Визуализация стека
Еще одна интересная возможность — это анализ не всего стека вызовов, а только той его части, которая, например, занимала больше всего ресурсов. Для этого на графике CPU Sampling by Process необходимо выбрать интересующий нас временной период и перестроить для него таблицу вызовов с помощью команды Summary Table. Также отметим, что для сравнения можно выбрать несколько интервалов и анализировать их в одновременно открытых окнах.
Использование символьной информации для визуализации стека вызовов является мощным средством анализа работы процессов и приложения. Вот несколько рекомендаций по успешному применению этой возможности:
для загрузки символов необходимо использовать либо команду Load Symbols в Windows Performance Analyzer, либо параметр -symbols при вызове утилиты XPerf;
для получения информации о параметре -symbols применяйте команду:
C:\>xperf –help symbols
убедитесь в том, что правильно установлено значение переменной среды:_NT_SYMBOL_PATH;
файл трассировки должен быть либо создан с помощью опции -d, либо объединен с другими файлами трассировки на том же компьютере с помощью опции -merge;
важно, чтобы символы для компонентов операционной системы и приложения относились именно к установленной на компьютере версии. Для проверки используйте утилиту symchk.exe из набора утилит Debugging Tools for Windows:
C:\> symchk /v <локальный файл > /s <символы.pdb>
для проверки соответствия двоичных файлов установленным на компьютере символам применяйте утилиту fc:
C:\> fc /b <локальный файл> <файл символов>
всегда указывайте, как минимум, флаги PROC_THREAD+LOADER — они позволяют собрать базовую информацию о жизненном цикле процесса и виртуальных адресах загрузки образов в память. Это нужно для того, чтобы убедиться в том, что события, связанные с процессами: Create, Delete, Start Rundown, End Rundown и образами Load, Unload, Start Rundown, End Rundown, присутствуют в таблице, получаемой с помощью следующей команды:
C:\> xperf -i имя_файла.etl -a tracestats -detail
Результат выполнения данной команды показан на рис. 9.
Рис. 9. События, связанные с процессами
 |
|
