Одна из самых мощных возможностей Xperf — проход стека, позволяющий отслеживать функции на протяжении конкретного временного интервала и выявлять операции, потребляющие большую часть ресурсов процессора. Данные прохода стека позволяют не только выяснить, на что тратится процессорное время, но и отследить путь выполнения процесса, приведшего к повышенному потреблению ресурсов. Xperf также позволяет выявить влияние изменений конфигурации на работу системы посредством сбора совокупных данных и проведения на их основе анализа производительности и характера потребления ресурсов. На данном ниже примере поэтапно показано выполнение прохода стека и интерпретация полученных данных.
Когда может быть полезен проход стека
Рассмотрим пример сценария, когда может оказаться полезен проход стека с помощью Xperf. Допустим, выполнив обновление Web-приложения, вы замечаете ухудшение производительности системы. С помощью Xperf и прохода стека выясняется, что процессор тратит время на рисование границы вокруг файла JPEG на Web-сайте. Анализ вызовов функций показывает, что каждое обращение к файлу JPEG сопровождается сотнями обращений к реестру и именно на это тратится все процессорное время. Если передать эту информацию разработчикам приложения или внутренним разработчикам, они быстро поймут, что все эти обращения к реестру излишни, а информацию можно держать в памяти, куда доступ осуществляется значительно быстрее и не требует такой интенсивной работы процессора.
Сбор данных трассировки с проходом стека
Для сбора данных трассировки с проходом стека с помощью Xperf необходимо сделать следующее.
Установить системные переменные для загрузки символов. Наилучший способ обеспечить правильную конфигурацию символов на целевой системе — установить две указанные ниже системные переменные. Установку этих переменных можно выполнить через командную строку, однако я рекомендую воспользоваться компонентом «Система» в панели управления либо щелкнуть правой клавишей «Мой компьютер», затем «Свойства», «Дополнительно» и «Переменные среды».
Первая системная переменная, которую необходимо установить, следующая:
_NT_SYMBOL_PATH = srv*c:\symbols*
http://msdl.microsoft.com/download/
symbols*c:\APP1
Разработчикам, возможно, потребуется добавить другие пути к символам собственных приложений или символам других разработчиков. В таком случае следует пользоваться символом «звездочка» (*) в качестве разделителя различных путей.
Вторая системная переменная:
_NT_SYMCACHE_PATH = c:\symbols
Установка этой переменной предписывает Xperf освобождать каждый символ от лишней информации (то есть структурных описаний) и создавать файл меньшего размера, что увеличит скорость загрузки символов и улучшит общее восприятие работы с Xperf при просмотре стеков.
Указать флаг прохода стека. Существует несколько способов использования флага прохода стека в Xperf. Ниже приведена типовая командная строка, которая предусматривает включение прохода стека для событий ядра и может применяться для диагностики проблем чрезмерно активного использования ресурсов процессора:
xperf -on latency -stackwalk profile
Для получения более полного списка событий путем прохода стека воспользуйтесь следующей командой:
xperf -help stackwalk
Включить загрузку символов. После сбора данных трассировки при просмотре файла полученных данных необходимо включить загрузку символов в окне просмотра Xperf.
Итак, выше перечислены три основных пункта действий, необходимых для использования функции прохода стека в Xperf. Вопрос: стоит ли включать функцию прохода стека при отсутствии доступа к символам? Да, но это зависит от обстоятельств. Без символов вы сможете увидеть только модуль внутри процесса, который является основным потребителем ресурсов процессора. Однако в некоторых случаях эта информация может оказаться достаточной для того, чтобы продвинуться в решении проблемы чрезмерной загрузки процессора.
Сбор и интерпретация данных трассировки
Рассмотрим поэтапный процесс сбора данных трассировки с проходом стека с их последующим анализом и интерпретацией.
Шаг 1. Введите команду Xperf. Откроется привычная командная строка, которую можно использовать для сбора данных, необходимых для диагностики проблемы чрезмерной загрузки процессора, с помощью функции прохода стека. После задания символов и установки Xperf нет необходимости в перезагрузке или перезапуске других служб. Теперь можно ввести следующую команду:
xperf -on latency -stackwalk profile
Данная команда предписывает включить трассировку для событий ядра, представляемых группой задержки, и включить профилировщик прохода стека для данного сеанса. Без указания флага «-stackwalk profile» просмотреть содержимое стека не удастся.
Шаг 2. Понаблюдайте за ходом трассировки и затем остановите ее. Необходимо дождаться возникновения пиковых значений загрузки процессора. Для наблюдения за ходом трассировки и ее остановки введите следующую команду:
xperf -d perf.etl
По умолчанию ETW (трассировка событий Windows) помещает информацию в файл kernel.etl. Ключ -d предписывает слить kernel.etl с именем заданного etl-файла (в частности, perf.etl).
Шаг 3. Откройте файл perf.etl. Теперь осталось открыть файл perf.etl в окне просмотра результатов анализа производительности (то есть в окне Xperf) с помощью следующей команды:
xperf perf.etl
Среда просмотра Xperf (также известная как Windows Performance Analyzer) содержит список схем, используемых для анализа данных. В окне просмотра можно выбрать интересующую область.
Чтобы сделать схему менее громоздкой, можно снять все отметки, кроме относящейся к анализируемому процессу, что я и сделал. В нашем случае пиковую загрузку процессора вызвал процесс WMIPrvse.exe. Задаем нужный временной интервал, щелкаем правой клавишей на выбранной области и выбираем Summary Table («Сводная таблица»).
В открывшейся сводной таблице щелкнем стрелку «шеврон» слева. Убедимся в наличии отметки флажка Stack. Загрузка символов и стека может занять несколько секунд. Сняв отметку флажков Module и Function, получим окно просмотра, как на экране 1.
Столбцы слева от желтой линии на экране 1 определяют порядок сортировки. То, что столбец Process — крайний левый, а за ним идет столбец Stack, означает сортировку времени процессора по процессам, а затем по стеку. Можно также сортировать по процессам, а затем по модулям, если доступ к символам отсутствует, и требуется лишь увидеть, какой из модулей является основным потребителем времени процессора.
Проведем интерпретацию данных. В строке заголовка сводной таблицы указан выбранный временной интервал. На экране 1 можно видеть, что выбранная область охватывает 2,5 секунды. Основной потребитель ресурсов на протяжении этого интервала — процесс WMIPrvse.exe, поскольку он занимает верхнюю позицию. Значения в столбце Weight соответствуют количеству данных, собранных за выбранный интервал. В частности, в нашем случае выбран интервал 2,5 секунды в ходе которого, как предполагается, имело место примерно 2500 событий, инициируемых в рамках сбора данных трассировки (суммарное значение в столбце Weight). Деятельность процессора была связана с процессом WMIPrvse.exe 1,859 секунды, что составляет 73,8% по отношению ко всем процессам, имевшим место на протяжении данного временного интервала.
Далее, щелкая значки (+), можно начать развертывать стек, чтобы выяснить, какие функции являются основными потребителями времени процессора. Можно также интерпретировать числовые значения в столбце Weight в пересчете 1 мс на событие — тогда 1859 переводится примерно в 1,8 секунды. Развертывая стек, ищите заметные падения значений времени в качестве анализируемых областей. В нашем примере на экране 2 показано падение с 1,14 до 0,57 секунды.
Разработчик начал бы анализировать вызовы функции cimwin32.dll в kernel32! FindFirstFileW. Администратор сразу сделал бы две вещи:
- Осуществил поиск в Internet обновления для cimwin32.dll
- Передал полученную информацию разработчику приложения. Если обновление не найдено, это значительно сократит время решения проблемы
Антиотладчик
Иногда отладка — единственный способ выяснить причину снижения производительности системы. Однако Xperf позволяет получить информацию о работе приложения путем сканирования имен вызовов функций и точно определить, куда уходит системное время. При этом не требуется знать единственную команду отладки или открывать файл дампа, а также быть экспертом в вопросах архитектуры Windows (хотя это не повредит!).
Майкл Моралес (morales@microsoft.com) — старший инженер службы поддержки Microsoft Global Escalation Services. Специализируется на проблемах отладки и производительности Windows