Какие-то из них относительно просты, другие потребуют времени и сил для освоения. Под катом вы найдете краткий обзор 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 отлично подходят для анализа на продакшне, хотя их можно использовать и в разработке. Главным недостатком этих решений является относительное неудобство их использования по сравнению с коммерческими профайлерами.
PerfView
Etrace and LiveStacks
Procdump and DebugDiag
Инструменты, описанные выше, прежде всего нацелены на оптимизацию производительности, хотя при помощи того же ETW я отловил множество багов и утечек памяти. Однако в некоторых случаях вам может понадобиться полный дамп памяти сломанного процесса, который можно было бы изучить на продакшен системе или потом в вашем development environment. В Windows есть несколько инструментов, предназначенных для создания дампов, мы здесь поговорим о двух из них: Procdump, очень гибкое бесплатное консольное приложение от Sysinternals, генерирующее дампы по различным триггерам (% использования CPU, объем используемой памяти, неотвечающие окна и прочие); и DebugDiag, инструмент для мониторинга, который можно очень тонко настроить для фонового отслеживания ваших процессов в ожидании неполадок. Есть очень много ошибок, найти которые можно лишь изучая дамп, или даже несколько дампов, сделанных с определенной периодичностью, поэтому создание инфраструктуры для получения таких дампов может стать задачей номер один.
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.
Этот список был бы неполным, если бы не еще одно приложение (которое Саша написал сам), предназначенное для решения одной весьма неприятной проблемки с анализом дампов: у меня были файлы с Windows Phone, а для WinPhone CLR нет публичного SOS расширения, столь нужного для любого вида управляемого анализа дампов в WinDbg. Потому я написал свой open-source дебаггер на основе Windows Debugging API (DbgEng) и библиотеки Microsoft CLRMD. Msos — это open-source фреймворк, предоставляющий SOS интерфейсам управляемую оболочку. Со временем msos оброс уникальными фичами, которые отделили его от WinDbg и SOS:
UPD. Мы снова делаем тренинг с Сашей, в этот раз в Москве: регистрация и условия участия есть на сайте.
Как исправить в Windows 10 загрузку жесткого диска 100%.
Публикация: 15 April 2018 Обновлено: 21 April 2018
Если ваш компьютер под управлением Windows 10 работает медленно, и вы обнаружите, что жесткий диск работает на уровне около 100%, выполните следующие действия, чтобы устранить данную проблему.
Иногда ваша система Windows 10 будет работать медленно, несмотря на то у вас мощный процессор, много оперативной памяти и всего лишь несколько приложений. Многие факторы могут вызвать медленную работу ПК, один из них заключается в том, что жесткий диск работает на уровне около 100%. Он не имеет запасных циклов для выполнения обычных задач ОС. В результате все замедляется. Простая перезагрузка, которая часто решает многие проблемы с ОС, не исправит загрузку диска. Существует рад моментов, которые вы можете сделать, чтобы исправить проблему 100% использования диска в Windows 10.
Устранение загрузки диска 100% в Windows 10.
Когда вы пытаетесь выяснить, почему компьютер тормозит, вы могли заметить, что использование Диска в диспетчере задач составляет 100%.
Отключить Windows Search.
Функция поиска Windows всегда индексирует все файлы на вашем диске и предназначена для ускорения поиска файлов на вашем ПК. Однако это может вызвать проблему, когда диск перегружен работой и не имеет ресурсов для выполнения других задач.
Нажмите правой кнопкой мыши меню Пуск и выберите Windows PowerShell (администратор).
Прокрутите список служб и дважды кликните службу «Windows Search», а на вкладке «Общие» установите для параметра «Тип запуска» значение «Отключено» и нажмите кнопку «ОК».
Запустите проверку диска.
Отключите функцию SuperFetch.
Если это исправило ситуацию, вы можете навсегда отключить его, как и в случае с Window Search (показано выше), отключив службу SuperFetch.
Прокрутите список служб и дважды кликните службу «SuperFetch», а на вкладке «Общие» установите для параметра «Тип запуска» значение «Отключено» и нажмите кнопку «ОК».
Отключите Windows Performance Recorder.
Выполните следующую команду, чтобы решить эту проблему с загрузкой жесткого диска.
Каждый раз при загрузке системы Windows 10 инструмент работает в фоновом режиме, поэтому вам нужно будет выполнить эту команду каждый раз при загрузке системы. После применения исправления, мое использование дискового пространства понизилось с 92% до 10%.
Вполне возможно, что использование диска является подлинной или что она была вызвана чем-то другим. Если после выполнения этой команды, вы получите сообщение » There are no trace profiles running.Error code: 0xc5583000 «, это означает, что инструмент Windows Performance Recorder не работает, и не является причиной этой проблемы.
Chrome или Skype.
Перейдите на вкладку «Безопасность» и нажмите кнопку «Изменить». Убедитесь, что выделены Все пакеты приложений и установите флажок Разрешить запись и нажмите «ОК».
Для Chrome наиболее распространенной проблемой является использование слишком большого количества ресурсов из за службы прогнозирования используемой для более быстрой загрузки страниц. Чтобы отключить его, перейдите в раздел «Дополнительные настройки» и в разделе «Конфиденциальность и безопасность» отключите «Использовать подсказки для ускорения загрузки страниц» и перезапустите браузер.
Если Вы столкнулись с этой проблемой на своем ПК с ОС Windows? Сообщите нам шаги, которые вы предприняли, чтобы исправить это.
Механизм трассировки событий для Windows
Одним из богатейших источников информации является провайдер ядра (kernel provider), который генерирует события в моменты запуска процессов и потоков, загрузки DLL, распределения блоков памяти, сетевых операций ввода/вывода и при выполнении трассировки стека. В таблице ниже приводится перечень некоторых наиболее интересных событий, сообщаемых ETW-провайдерами ядра и CLR. Механизм ETW можно использовать для исследования общего поведения системы, например, чтобы выяснить, какой из процессов потребляет большую часть вычислительной мощности CPU, проанализировать узкие места в операциях ввода/вывода, получить статистику, касающуюся работы сборщика мусора и использования памяти управляемыми процессами, и во многих других случаях, обсуждаемых далее.
События ETW несут в себе точное время их возникновения, могут содержать дополнительную пользовательскую информацию, а также состояние стека на момент их появления. Информация о состоянии стека может использоваться для выявления источников различных проблем. Например, провайдер CLR может посылать события в начале и в конце каждого цикла сборки мусора. Эти события в комплексе с информацией о состоянии стека вызовов можно использовать для выявления частей программы чаще других вызывающих сборку мусора.
| Провайдер | Флаг/ключевое слово | Описание | События |
|---|---|---|---|
| Ядро | PROC_THREAD |
