Windows performance recorder что это

Время на прочтение7 мин

Количество просмотров22K

В недавнем интервью с Джоном Скитом мы пришли к выводу, что профессиональная работа с любой технологией подразумевает умение диагностировать проблемы и понимать, как ваши приложения работают под капотом. Вдогонку к тому разговору, я узнал у Саши goldshtn Гольдштейна, одного из лучших в мире экспертов по производительности .NET, автора книги «Pro .NET Performance», на какие инструменты следует обратить внимание .NET-разработчикам.

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

Картинка с сайта: habr.com

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

Typeperf and Perfmon

Счетчики производительности Windows — первый шаг к получению высокоуровнего обзора того, чем занята ваша система. Мониторинг использования CPU и памяти, диска и I/O, сетевых пакетов и HTTP-запросов позволяет получить обзор работы системы с высоты «птичьего полета» с малым оверхэдом и понять, куда копать дальше. Perfmon (Performance Monitor) является встроенным в Windows инструментом, который не только предоставляет доступ к панели счетчиков производительности в реальном времени, но и позволяет записывать данные счетчиков, чтобы посмотреть их позже на другом компьютере, и даже настроить автоматические уведомления на случай, если что-то пойдет не так. Для любителей командной строки есть Typeperf — инструмент, записывающий данные счетчиков в CSV файл, который впоследствии можно легко парсить и автоматически анализировать. Эти два инструмента позволяют быстро понять, на что следует обратить внимание в первую очередь, а также нормально ли работает ваша система. Впрочем, для глубокого исследования они, конечно, не подходят, поскольку счетчики просто показывают вам цифры, отображающие те или иные аспекты работы операционной системы.

• Typeperf documentation on TechNet
• Perfmon documentation on TechNet

Картинка с сайта: habr.com

XPerf, WPR, and WPA (Windows Performance Toolkit)

За последние 10 лет ETW (Event Tracing for Windows) стал весьма распространенным инструментов и по факту оказался стандартом де-факто среди инструментов анализа производительности под Windows. Записывая и анализируя данные ETW, можно на уровне ОС осуществлять профайлинг ЦПУ, исследовать блокировки, выяснять, какие части вашего приложения создают высокую нагрузку на диск или на сеть, и даже отслеживать сборку мусора, аллокации памяти и события загрузки сборок самого NET. XPerf — более старый консольный инструмент для записи ETW событий, имеющий несколько аналитических модулей для измерения производительности I/O, составления отчетов работы CPU и расчета «стоимости» запуска приложений. Кроме того, он умеент конвертировать записи ETW в CSV формат, который можно легко парсить другими инструментами и скриптами. WPR (Windows Performance Recorder) — графическая оболочка, позволяющая выбирать события, которые вы хотели бы записать.

Есть еще WPA (Windows Performance Analyzer), современный инструмент для просмотра записей ETW, способный строить графики, сводные таблицы с разными фильтрами и группировками, а также отдельные вьюшки для определенных событий: CPU стэков, аллокаций памяти, I/O запросов и этапов загрузки. Совсем недавно появилась поддержка flame graphs, нового метода отображения больших деревьев стека, позволяющий с легкостью их анализировать.

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

Windows Performance Toolkit documentation on MSDN

Картинка с сайта: habr.com

PerfView

Основная проблема инструментов Windows Performance Toolkit заключается в том, что они не заточены под мониторинг на управляемые процессы и CLR-специфичные события, такие как сборка мусора, управляемые исключения, загрузка сборок или JIT-компиляция. PerfView представляет из себя open source инструмент от Microsoft, который может записывать, собирать и отображать события CLR, включая те собтия, которые вы инициируете сами при помощи EventSource API, доступном начиная с .NET 3.5. У PerfView есть несколько уникальных возможностей: например, отображение дампов кучи управляемых процессов в очень удобном виде (в котором очень легко обнаруживать утечки памяти); сворачивание и группировка стэков вызовов, позволяющая быстро разбираться с тысячами data points, и сбор данных по .NET событиям вроде GC и аллокаций. К сожалению, интерфейс PerfView делал перфоманс-инженер, так что он не слишком интуитивен и требует определенного периода привыкания, после которого вы сможете работать с инструментом на все 100.

Про PerfView Саша рассказывал на прошлом DotNext в Петербурге.

PerfView tutorial video series on Channel 9

Etrace and LiveStacks

На DotNext 2017 Piter Саша представит несколько собственных open source разработок, которые он сам использует для «очного» исследования производительности и которые не требуют генерации больших объемов данных и последующего их анализа. Первый из них — etrace, который генерирует живой лог интересных ETW событий и дает много возможностей по их фильтрации. Пример: вы можете попросить etrace вывести сообщение в момент использования какого-либо конкретного файла, когда в процессе происходит полная (generation 2) сборка мусора, когда загружается какая-то конкретная .NET assembly, или когда ASP.NET-приложение бросает управляемое исключение. Работа из командной строки позволяет использовать etrace в скриптах и быстро получать результаты, не копаясь в GUI.

Второй инструмент — LiveStacks, похожий на профайлер инструмент, предназначенный для захвата и объединения стеков событий в реальном времени. Если точнее, то LiveStacks собирает управляемые стеки вызовов (имена методов), исследуя память целевого процесса, в отличие от традиционного ETW подхода, требующего завершения сессии профилирования для генерирования и парсинга CLR rundown events. Как результат такого подхода — быстрый, легковесный и эффективный инструмент, способный сохранять стек в компактном виде, пригодном для формирования flame graph. Если вам нужны быстрые результаты на продакшне и вы не брезгуете поработать в консоли, надеюсь, эти инструменты будут вам полезны.

• etrace GitHub repository
• LiveStacks GitHub repository

Картинка с сайта: habr.com

Procdump and DebugDiag

Инструменты, описанные выше, прежде всего нацелены на оптимизацию производительности, хотя при помощи того же ETW я отловил множество багов и утечек памяти. Однако в некоторых случаях вам может понадобиться полный дамп памяти сломанного процесса, который можно было бы изучить на продакшен системе или потом в вашем development environment. В Windows есть несколько инструментов, предназначенных для создания дампов, мы здесь поговорим о двух из них: Procdump, очень гибкое бесплатное консольное приложение от Sysinternals, генерирующее дампы по различным триггерам (% использования CPU, объем используемой памяти, неотвечающие окна и прочие); и DebugDiag, инструмент для мониторинга, который можно очень тонко настроить для фонового отслеживания ваших процессов в ожидании неполадок. Есть очень много ошибок, найти которые можно лишь изучая дамп, или даже несколько дампов, сделанных с определенной периодичностью, поэтому создание инфраструктуры для получения таких дампов может стать задачей номер один.

Procdump documentation on TechNet
DebugDiag documentation on MSDN

WinDbg

Вообще, для анализа дампов и получения из них максимума информации можно использовать Visual Studio, однако лучше обратить внимание на WinDbg и его всевозможные расширения. WinDbg, Windows Debugger, это мощный и очень unfriendly инструмент для отладки работающих процессов и анализа дампов. Вооружившись расширениями (такими как SOS, SOSEX, NetExt, and MEX), вы получите огромные возможности: исследование управляемой кучи, поиск неиспользуемых и неудаляемых объектов, находить задедлоченные потоки одной командой, обнаруживать ASP.NET запросы в реальном времени и делать множество других исследований. Важно отметить, что WinDbg можно управлять как внешними скриптами (запуская его из командной строки с определенными параметрами), так и внутренними (написанными на скриптовых языках или C/C++/C# DLL). Все это дает значительно более гибкие возможности для отладки в сравнении с VS или другими IDE, а его легковесность позволяет ставить его на продакшн и использовать для real-time мониторинга. Поверьте, вы оцените эту возможность не копировать к себе 50 гигабайтный дамп, когда окажется, что ваш сервер находится за 5000 километров от вас, а ширина канала не превышает 1 мегабита в секунду.

Кстати, на прошлом DotNext, Саша уже рассказывал много интересного про WinDbg.

WinDbg reference on MSDN

Картинка с сайта: habr.com

Msos

Этот список был бы неполным, если бы не еще одно приложение (которое Саша написал сам), предназначенное для решения одной весьма неприятной проблемки с анализом дампов: у меня были файлы с Windows Phone, а для WinPhone CLR нет публичного SOS расширения, столь нужного для любого вида управляемого анализа дампов в WinDbg. Потому я написал свой open-source дебаггер на основе Windows Debugging API (DbgEng) и библиотеки Microsoft CLRMD. Msos — это open-source фреймворк, предоставляющий SOS интерфейсам управляемую оболочку. Со временем msos оброс уникальными фичами, которые отделили его от WinDbg и SOS:

• Запросы выборок объектов из кучи, например «Найди все HTTP запросы, ожидающие более 2 секунд» или «найди все объекты типа CustomerData где параметр AmountDue отрицательный»;
• Обнаружение дедлоков в управляемых и native механизмах синхронизации;
• Поддержка индексации хипа для быстрого обхода графов;
• Кастомный генератор дампов памяти, игнорирующий регионы памяти, ненужные для анализа управляемых дампов (таким образом сохраняя до 80% дискового пространства);
• Режим автоматической сортировки, генерирующий лаконичный JSON отчет с минимумом данных, требуемых для более глубокого исследования. Я понимаю, что большинство из вас продолжит использовать VS для повседневной отладки, и это нормально. Однако мой инструмент позволит вам справляться с самыми неприятными ситуациями.

msos GitHub repository

Надеюсь, было полезно. А если хотите подробностей —

на тренинг еще осталось несколько билетов.

UPD. Мы снова делаем тренинг с Сашей, в этот раз в Москве: регистрация и условия участия есть на сайте.

Windows Performance Recorder is a useful tool for troubleshooting computer problems. It’s easy to install, run, and work with Windows.

Windows Performance Recorder (WPR) and Windows Performance Analyzer are two separate utilities that make up the Windows Performance Toolkit (WPA).

A performance recording tool based on Event Tracing for Windows (ETW) is called Windows Performance Recorder (WPR). It logs system and application events, which can then be used by Windows Performance Analyzer (WPA) to inspect.

Windows Performance Analyzer (WPA) is a program that generates graphs and tables of data using Event Tracking for Windows (ETW) events that have been recorded by Windows Performance Recorder (WPR), Xperf, or assessments that have been run on the Assessment Platform. Any event trace log (ETL) file can be opened by WPA for analysis.

To view specific performance issues and get an overview of resource usage, use WPR in conjunction with WPA. Development and IT workers can proactively identify and address performance issues thanks to WPR and WPA.

Install Windows Performance Recorder

Along with other performance tools such as Windows Performance Analyzer and Xperf, Windows Performance Recorder (WPR) is a component of the Windows Assessment and Deployment Kit (Windows ADK).

Download WPR on Windows Assessment and Deployment Kit (Windows ADK)

1. Run ADKSetup.exe the result of the download.
2. Select where the Windows ADK should be installed by clicking Install, and then clicking Next.
3. Click Install after selecting the Windows Performance Toolkit (ADK) features you want to install. Other than the Windows Performance Toolkit, nothing else needs to be installed. The entire ADK does not have to be installed (or SDK).

Start Windows Performance Recorder Recording

1. Open Windows Performance Recorder.
2. Select at least one profile from the list in the Select a profile box.  The addition of a unique profile is optional. To do so, click “Add Profiles”, select the desired profile, and then click Open.

1. Select the desired scenario from the “Performance scenario” drop-down list. Select “General” except recording for on/off scenarios such as sleep, shutdown, reboot, etc.
2. Select the detail level of the report, you can choose “Verbose” (default) and “Light”.
3. Select File from the Logging mode drop-down menu to save the recording to a file. Except for the on/off transition log, which must be written to a file, memory is the default logging mode.
4. To start or stop recording, select Start or Cancel.

Turn off Windows Performance Recorder recordings

1. Klik Save on the WPR screen. (No recording data is saved if you click  Cancel.)
2. Select the location where you want to save the recording file by browsing there.
3. Provide a summary of the issue the record wants to address.
4. Click OK after clicking Save.

View Windows Performance Recorder Recording Status

The recording status appears on the WPR screen as soon as you start the recording using the WPR user interface (UI).

WPR can only provide the status of a record if WPR starts its recording first. It cannot display the status of records that have been started by Xperf or other programs.

The following details are displayed in the recording state:

• Recording Time: The recording has been played all along.
• Buffer: The size of the buffer used to record is this. It is displayed in MB and as a proportion of the available combined memory.
• Events dropped: how many events have been lost since the recording first started?

Средство записи производительности Windows (WPR) входит в комплект средств для оценки и развертывания Windows (Windows ADK) и представляет собой средство записи производительности, основанное на трассировке событий Windows (ETW). Он записывает события системы и приложения, которые затем можно проанализировать с помощью Windows Анализатор производительности (WPA). WPR можно использовать вместе с Windows Анализатор производительности (WPA) для изучения определенных областей производительности и получения общего представления о потреблении ресурсов. WPR и WPA позволяют специалистам по разработке и ИТ-специалистам заблаговременно выявлять и устранять проблемы с производительностью. Для WPR требуется Windows 8 или более поздней версии.

Где получить средство записи производительности Windows

Средство записи производительности Windows (WPR) входит в комплект средств оценки и развертывания Windows (Windows ADK) наряду с другими средствами производительности, такими как Windows Анализатор производительности и Xperf.

Вы можете скачать WPR, перейдя на страницу Комплект средств оценки и развертывания Windows (Windows ADK).

Новые возможности WPR

Список новейших функций WPR см. в разделе WPR статьи Новые возможности набора средств для повышения производительности Windows.

В этом разделе

Связанные темы

Технический справочник по набору средств производительности Windows

Справочник по Command-Line Xperf

Windows Performance Analyzer

by: ,
published: Jul 2, 2013,
updated: Dec 9, 2015, in

In the last five years Xperf has gained popularity as an administrator’s secret weapon for battling all kinds of performance issues. But just when it was on the brink of becoming as mainstream as such a tool can be, Microsoft superseded it by something else: Windows Performance Recorder.

To understand why we need to take a look at the recommended command line for capturing boot traces:

xbootmgr -trace boot -traceflags base+latency+dispatcher -stackwalk profile+cswitch+readythread -notraceflagsinfilename

Hmm, not very intuitive. It turns out Microsoft came to the same conclusion: obtaining traces with Xperf was, at times, very complex. Knowing which providers and stackwalking flags to enable was a struggle all together.

They are right, of course. Selecting the best options for each type of trace is a bit like Alchemy with Xperf. It makes a lot of sense to wrap that into a UI. They did and called it Windows Performance Recorder. It comes as part of the Windows Assessment and Deployment Kit (ADK) for Windows 8, but works on Windows 7 / Server 2008 R2, too. Just as with Xperf and Xperfview there is a separate component for analysing the traces called Windows Performance Analyzer.

The Problem

The problem I was trying to analyze was this: a customer was finding that a laptop, freshly installed with the corporate image, was taking 3.5 minutes to boot to a usable state (by that I mean from the time Windows starts until CPU and hard disk load have dropped so that the system can actually be put to use).

Creating the Trace

I reinstalled Windows on one of the corporate laptops, waited for the full disk encryption to finish and rebooted a few times to give Windows ReadyBoot enough time to do its optimization magic.

Then I prepared the system for WPR by running the following command:

wpr -disablepagingexecutive on

Do not forget to turn it back off when you are done as it can adversely affect performance.

Then I configured the boot trace options in Windows Performance Recorder (wprui.exe):

Картинка с сайта: helgeklein.com

I rebooted to create the trace. Then I ran wprui.exe again to have it stop the trace and save the trace file, which took up a whopping 3 GB on the hard disk.

Analyzing the Trace

When I opened the trace file Windows Performance Analyzer (wpa.exe) displayed CPU, IO and memory loads as well as potential delays in these default graphs:

The storage graph looked most interesting. I took a closer look: by double-clicking the graph it was opened in the main window area:

Картинка с сайта: helgeklein.com

With the disk utilization nearly constantly at 100% it was evident that the hard drive was overloaded. That conclusion was easily confirmed by watching the hard disk LED: during the boot phase it was not flickering, but glowing brightly.

The obvious question was: what was generating all those IOs? To find out I expanded Storage and then Disk Usage, dragged Counts by Process, IO Type to the main window and got this:

Картинка с сайта: helgeklein.com

It was clear that many different processes contributed to the IO load (each line in the chart represents one process). To confirm this I switched the Disk Usage display mode from graph only to table only and sorted by IO count:

In addition to the system and other OS components we have:

• McAfee antivirus
• various Windows services (notably Offline Files)
• Matrix 42 Empirum (software distribution agent)
• App-V client
• Citrix Receiver
• a component written in-house by the customer

Hypothesis

My hypothesis was this: there was just too much going on for the poor magnetic hard drive. To test it, I replaced the laptop’s disk with an SSD (nothing special, just some boring 160 GB Intel model). Then I reinstalled the machine, performed the same preparatory steps as before and finally measured the boot time: it had dropped from 210 to 50 seconds.

Hypothesis confirmed.

Conclusion, and How to Monitor Boot Times

Windows Performance Recorder & Analyzer are powerful tools for analyzing performance problems. The complexity of creating traces has been reduced a lot compared to Xperf, but the really difficult thing still is the interpretation of the results, of course. If you know how to do that WPR/WPA give you great information about a single system.

Obviously, creating traces with WPR is something you only do when you already know boot time is bad. But how do you find out? Waiting for users to complain is probably not the best technique, you might want to be a bit more proactive.

uberAgent for Splunk, our user experience monitoring tool, gives you everything you need to keep boot performance snappy. It reports on boot duration across all machines…

Картинка с сайта: helgeklein.com

…identifies computers that boot slowly…

Картинка с сайта: helgeklein.com

…and even gives you probable causes:

Картинка с сайта: helgeklein.com

Try it yourself for free!