В недавнем интервью с Джоном Скитом мы пришли к выводу, что профессиональная работа с любой технологией подразумевает умение диагностировать проблемы и понимать, как ваши приложения работают под капотом. Вдогонку к тому разговору, я узнал у Саши goldshtn Гольдштейна, одного из лучших в мире экспертов по производительности .NET, автора книги «Pro .NET Performance», на какие инструменты следует обратить внимание .NET-разработчикам.
Какие-то из них относительно просты, другие потребуют времени и сил для освоения. Под катом вы найдете краткий обзор 12 инструментов, которые будут полезны перфоманс-инженерам, специалистам поддержки вернего уровня и вообще разработчикам, пекущимся о производительности своих приложений.
Подробнее про все инструменты и про то, как с их помощью решать проблемы с производительностью ваших приложений на практике Саша расскажет 21 мая на тренинге в Петербурге.
Счетчики производительности Windows — первый шаг к получению высокоуровнего обзора того, чем занята ваша система. Мониторинг использования CPU и памяти, диска и I/O, сетевых пакетов и HTTP-запросов позволяет получить обзор работы системы с высоты «птичьего полета» с малым оверхэдом и понять, куда копать дальше. Perfmon (Performance Monitor) является встроенным в Windows инструментом, который не только предоставляет доступ к панели счетчиков производительности в реальном времени, но и позволяет записывать данные счетчиков, чтобы посмотреть их позже на другом компьютере, и даже настроить автоматические уведомления на случай, если что-то пойдет не так. Для любителей командной строки есть Typeperf — инструмент, записывающий данные счетчиков в CSV файл, который впоследствии можно легко парсить и автоматически анализировать. Эти два инструмента позволяют быстро понять, на что следует обратить внимание в первую очередь, а также нормально ли работает ваша система. Впрочем, для глубокого исследования они, конечно, не подходят, поскольку счетчики просто показывают вам цифры, отображающие те или иные аспекты работы операционной системы.
За последние 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
Основная проблема инструментов 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
На DotNext 2017 Piter Саша представит несколько собственных open source разработок, которые он сам использует для «очного» исследования производительности и которые не требуют генерации больших объемов данных и последующего их анализа. Первый из них — etrace, который генерирует живой лог интересных ETW событий и дает много возможностей по их фильтрации. Пример: вы можете попросить etrace вывести сообщение в момент использования какого-либо конкретного файла, когда в процессе происходит полная (generation 2) сборка мусора, когда загружается какая-то конкретная .NET assembly, или когда ASP.NET-приложение бросает управляемое исключение. Работа из командной строки позволяет использовать etrace в скриптах и быстро получать результаты, не копаясь в GUI.
Второй инструмент — LiveStacks, похожий на профайлер инструмент, предназначенный для захвата и объединения стеков событий в реальном времени. Если точнее, то LiveStacks собирает управляемые стеки вызовов (имена методов), исследуя память целевого процесса, в отличие от традиционного ETW подхода, требующего завершения сессии профилирования для генерирования и парсинга CLR rundown events. Как результат такого подхода — быстрый, легковесный и эффективный инструмент, способный сохранять стек в компактном виде, пригодном для формирования flame graph. Если вам нужны быстрые результаты на продакшне и вы не брезгуете поработать в консоли, надеюсь, эти инструменты будут вам полезны.
Инструменты, описанные выше, прежде всего нацелены на оптимизацию производительности, хотя при помощи того же ETW я отловил множество багов и утечек памяти. Однако в некоторых случаях вам может понадобиться полный дамп памяти сломанного процесса, который можно было бы изучить на продакшен системе или потом в вашем development environment. В Windows есть несколько инструментов, предназначенных для создания дампов, мы здесь поговорим о двух из них: Procdump, очень гибкое бесплатное консольное приложение от Sysinternals, генерирующее дампы по различным триггерам (% использования CPU, объем используемой памяти, неотвечающие окна и прочие); и DebugDiag, инструмент для мониторинга, который можно очень тонко настроить для фонового отслеживания ваших процессов в ожидании неполадок. Есть очень много ошибок, найти которые можно лишь изучая дамп, или даже несколько дампов, сделанных с определенной периодичностью, поэтому создание инфраструктуры для получения таких дампов может стать задачей номер один.
Procdump documentation on TechNet
DebugDiag documentation on MSDN
Вообще, для анализа дампов и получения из них максимума информации можно использовать 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
Этот список был бы неполным, если бы не еще одно приложение (которое Саша написал сам), предназначенное для решения одной весьма неприятной проблемки с анализом дампов: у меня были файлы с Windows Phone, а для WinPhone CLR нет публичного SOS расширения, столь нужного для любого вида управляемого анализа дампов в WinDbg. Потому я написал свой open-source дебаггер на основе Windows Debugging API (DbgEng) и библиотеки Microsoft CLRMD. Msos — это open-source фреймворк, предоставляющий SOS интерфейсам управляемую оболочку. Со временем msos оброс уникальными фичами, которые отделили его от WinDbg и SOS:
msos GitHub repository
Надеюсь, было полезно. А если хотите подробностей —на тренинг еще осталось несколько билетов.
А если целый день отладке и производительности вы уделять не хотите, то встретиться с Сашей и еще 30 .NET-гуру со всего мира можно будет на DotNext 2017 Piter.
UPD. Мы снова делаем тренинг с Сашей, в этот раз в Москве: регистрация и условия участия есть на сайте.
Какие-то из них относительно просты, другие потребуют времени и сил для освоения. Под катом вы найдете краткий обзор 12 инструментов, которые будут полезны перфоманс-инженерам, специалистам поддержки вернего уровня и вообще разработчикам, пекущимся о производительности своих приложений.
Подробнее про все инструменты и про то, как с их помощью решать проблемы с производительностью ваших приложений на практике Саша расскажет 21 мая на тренинге в Петербурге.
Typeperf and Perfmon
Счетчики производительности Windows — первый шаг к получению высокоуровнего обзора того, чем занята ваша система. Мониторинг использования CPU и памяти, диска и I/O, сетевых пакетов и HTTP-запросов позволяет получить обзор работы системы с высоты «птичьего полета» с малым оверхэдом и понять, куда копать дальше. Perfmon (Performance Monitor) является встроенным в Windows инструментом, который не только предоставляет доступ к панели счетчиков производительности в реальном времени, но и позволяет записывать данные счетчиков, чтобы посмотреть их позже на другом компьютере, и даже настроить автоматические уведомления на случай, если что-то пойдет не так. Для любителей командной строки есть Typeperf — инструмент, записывающий данные счетчиков в CSV файл, который впоследствии можно легко парсить и автоматически анализировать. Эти два инструмента позволяют быстро понять, на что следует обратить внимание в первую очередь, а также нормально ли работает ваша система. Впрочем, для глубокого исследования они, конечно, не подходят, поскольку счетчики просто показывают вам цифры, отображающие те или иные аспекты работы операционной системы.
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
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. Если вам нужны быстрые результаты на продакшне и вы не брезгуете поработать в консоли, надеюсь, эти инструменты будут вам полезны.
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
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
Надеюсь, было полезно. А если хотите подробностей —
А если целый день отладке и производительности вы уделять не хотите, то встретиться с Сашей и еще 30 .NET-гуру со всего мира можно будет на DotNext 2017 Piter.
UPD. Мы снова делаем тренинг с Сашей, в этот раз в Москве: регистрация и условия участия есть на сайте.
