Microsoft windows performance toolkit что это

Windows Performance Toolkit

в состав комплекта средств для развертывания и оценки WindowsWindows набор средств производительности входят средства мониторинга производительности, создающие подробные профили производительности Windows операционных систем и приложений. в этой документации обсуждаются Windowsная запись производительности (звч) и анализатор производительности Windows (WPA).

Windows компонентов набор средств производительности

набор средств производительности Windows состоит из двух независимых средств: Windows средства записи производительности (звч) и анализатора производительности (WPA) Windows. Кроме того, поддерживается предыдущее средство командной строки XPerf. Однако Ксперфвиев больше не поддерживается. Все записи должны быть открыты и проанализированы с помощью WPA.

ниже приведены требования к системе для запуска Windows набор средств производительности.

средство записи производительности Windows (звч): Windows 8 или более поздней версии.

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

Основные процедуры и подробное пошаговое руководство см. в быстрое Началое по ЗВЧ. Полную документацию по пользовательскому интерфейсу ЗВЧ см. в разделе функции ЗВЧ. Справочные сведения о параметрах командной строки см. в разделе параметры Command-Line ЗВЧ. Пошаговые инструкции см. в разделах Практическое руководство по ЗВЧ. Дополнительные сведения о ключевых сценариях см. в статье сценарии ЗВЧ. Полный справочный материал, включая XML-ссылку профиля записи и устаревший Справочник по XPerf, см. в справочнике по ЗВЧ.

Windows Performance Analyzer

WPA — это мощное средство анализа, объединяющее очень гибкий интерфейс с обширными возможностями построения диаграмм и таблицами данных, которые могут быть сведены и иметь возможности полнотекстового поиска. WPA предоставляет окно проблем для изучения основной причины любого обнаруженного.

Основные процедуры и подробное пошаговое руководство см. в Краткое руководство по началу работы WPA. Полную документацию по пользовательскому интерфейсу ЗВЧ см. в разделе функции WPA. Пошаговые инструкции см. в разделах Практическое руководство по WPA. Дополнительные сведения о ключевых сценариях см. в статье сценарии WPA.

Источник

990x.top

Простой компьютерный блог для души)

WPTx64 — что это за программа и нужна ли она? (Windows Performance Toolkit)

Приветствую друзья! Иногда можно посмотреть список установленного софта на ПК и удивиться наличию неизвестных программ. Откуда они? Ответ прост — при установке софта часто вместе с ним ставятся и дополнительные компоненты. Особенно это касается тяжелого софта, например Microsoft Office, ПО Adobe.

WPTx64 — что это такое?

Набор средств для оценки производительности Windows.

Данный компонент необходим для работы софта SOLIDWORKS (подробности здесь).

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

Возможно компонент имеет отношение к таким встроенным инструментам Windows как Системный монитор и Монитор ресурсов.

WPTx64 является частью пакета SDK и комплекта средств оценки и развертывания Windows. Инфа взята с офф сайта, как понимаю — это часть операционки, поэтому удалять не стоит.

Инструмент Windows Software Development Kit, при помощи которого и можно установить данный компонент:

Устанавливается в эту папку:

C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit

Или просто в Program Files, без x86. Полное название установщика может быть таким — WPTx64-x86_en-us.

WPTx64 — можно ли удалить?

Важно: при установленном ПО SOLIDWORKS удалять WPTx64 не рекомендуется!

С одной стороны это системный компонент, который нужен для оценки производительности, для определения проблем. Но возможно без него можно обойтись. Чтобы не гадать — перед удалением нужно сделать страховку в виде точки восстановления:

После — можно удалять WPTx64:

Источник

Ускорение загрузки Windows for fun and profit

Пожалуй, начну с того, что если перегружаться 15 раз в год, то любой «тюнинг» процесса загрузки отнимает больше времени, чем будет выиграно на перезагрузках за все время жизни системы. Однако, спортивный интерес берет свое, тем более, что люди интересуется процессом оптимизации быстродействия. А загрузка оказалась самым очевидным кандидатом в примеры того, как на мой взгляд должен выглядеть этот самый процесс. Сразу скажу, что грузиться будем с 5400 rpm винта, грузиться будем в «рабочую» систему: помимо недобитой вендорской крапвари там стоит еще куча всякого типа вижуал студии, антивируса, скайпа, стима, гуглапдейтера и пр…

Про то, почему отключение pagefile-а скорее вредно, чем полезно — как нибудь в другой раз, а пока…

Конкретных и общеприменимых советов по оптимизации работы ОС быть не может точно так же как не может быть конкретных советов по ускорению работы любой случайно взятой программы. Точно так же как и в отдельных программах, работа всей системы может быть серьезно замедлена из-за одного-двух на первый взгляд незначительных мест. Для нахождения подобных «бутылочных горлышек» в программах существуют инструменты, называемые профайлерами. Нет ничего странного, что для нахождения «бутылочных горлышек» в операционной системе мы тоже будем использовать профайлер (никаких кавычек — это действительно профайлер причем одновременно и sampled и instrumented). С недавних пор WPA Tools распространяются в составе Windows SDK. Ставить полный SDK совершенно необязательно. Можно установить только «Windows Performance Toolkit»:

После перезагрузки в каталоге, в котором эта команда была выполнена останется файл «boot_BASE+CSWITCH_1.etl» (BASE+CSWITCH это те самые «ключевые слова»): xperf boot_BASE+CSWITCH_1.etl

И можно начинать просмотр. Увиденное навевает печаль:

Explorer готов к 36-й секунде, но из-за 100% загрузки единственного (не особо быстрого) диска, система еще 2 минуты будет не очень отзывчивой (меню пуск будет открываться мгновенно, а вот с запуском программ придется подождать). ReadyBoot пытается чего то сделать и сначала у него даже получается (оранжевое и зеленое), но постепенно накапливающиеся отклонения от бутплана сводят его попытки на нет.
Что еще печальнее, так это то, что вместо собственно чтения данных, большую часть своей стопроцентной занятости диск проводит в метаниях головки к центру диска и обратно:

Небольшая справка: ReadyBoot собирает профиль использования диска при каждой загрузке и потом сервис SysMain строит бутплан на основании пяти последних загрузок. Соответственно, чем чаще загружаетесь, тем лучше будет «угадан» бутплан на следующую загрузку и тем быстрее она будет. Помимо этого, префетчер собирает статистику о том, какие файлы и в каком порядке были использованы во время загрузки и складывает эту информацию в %SystemRoot%\Prefetch\Layout.ini

Эту информацию использует встроенный дефрагментатор для принятия решений о размещении файлов.

Соответственно первой «оптимизацией» будет многократная перезагрузка и дефрагментация. Очень удобно, что xbootmgr может сделать это за нас.

После второй начинается дефрагментация:

Когда все закончится, в каталоге, из которого был запущен xbootmgr останется 6 файлов с трейсами каждой из подготовительных перезагрузок а также все тот же boot_BASE+CSWITCH_1.etl

Смотрим, изменилось ли чего нибудь. А все изменилось довольно заметно:

ReadyBoot справляется со своей задачей значительно лучше и как следствие эксплорер готов на треть быстрее, а время активности диска сократилось почти вдвое.

Мы все еще ходим в центр диска и этим мы займемся позже, но disk seek-ов уже заметно меньше, и это уже какой никакой, а успех. Пока же, обратим внимание на такой график:

Это же безобразие. Пока кто то выкладывается на 100%, некоторые отдыхают. Будем исправлять. Как обычно разменивают процессоное время на размер читаемых данных? Правильно, компрессией. Исправлять будем сжатием папок Windows и обоих Program Files-ов. Попытку сделать это из загруженной системы нельзя назвать успешной — какие то файлы пакуются, какие то нет. В общем так жить нельзя:

Перегружаемся в System Recovery и выполняем оттуда compact /c /a /i /s: каталог для наших трех каталогов. Скриншотов не будет, так как мне было сильно лень делать скриншотилку для WinPE — придется поверить на слово (а лучше перепроверить экспериментально). prepSystem придется провести еще раз, так как layout диска после сжатия сильно поменялся.

Ну и проверяем, чего у нас вышло-то:

Эксплорер готов к 20-й секунде, еще чуть меньше минуты идет дисковая активность, но уже чуть меньше 100%.

И да, мы все еще ходим в центр диска:

Тултипы подсказывают нам виновника. Перепроверям

Заодно под раздачу попадают скайп и стим. И правильно — нечего им делать в автозагрузке с такими аппетитами. Их всегда можно запустить из супербара/старт меню.

Совершенно невменяемое время загрузки одного сервиса:

Мы договорились не отказываться от функционала, даже если он нам на фиг не уперся. Поэтому отключать сервисы мы не будем. Мы просто переключим их в «Automatic (Delayed start)»:

В случае с Microsoft Antimalware все несколько сложнее:

Достаточно быстро выясняем, что дело в том, что сервис относится к группе «COM Infrastructure» и не может быть загружен позже этой группы. Идем в реестр и вытаскиваем его из этой группы, после чего спокойно доделываем дело:

На всякий случай еще один prepSystem и вот финал:

Эксплорер загрузился на 17-й секунде, на 18-й фактически прекращается дисковая активность.

Можно полюбоваться на строго упорядоченный доступ к диску:

Быстрый SSD и/или тотальное вырезание функционала могло бы сократить время загрузки до десяти секунд и меньше.

А вывод из всего этого такой: прежде чем что либо «оптимизировать», стоит определить те минимальные изменения, которые возымеют максимальный результат.

Источник

Ускорение загрузки Windows 7 с помощью Windows Performance Toolkit

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

Так как я не любитель программ от разных производителей, обещающих 1000% прирост скорости ПК, а так же попутно «почистить реестр», используем программу предоставленную компанией Microsoft — Windows Performance Toolkit.

В отличии от разных поделок «все в одном», после использования данной утилиты от Microsoft, ни один ПК не пострадал(за много лет использования). 🙂

Вообще Windows Performance Toolkit, это профайлер — т.е продукт предназначенный для динамического анализа активности программ.

Т.е. оптимизация, это всего лишь часть его функции, в целом он нужен для поиска «узких мест» системы. И если вас интересует подробный анализ загрузки вашего ПК, то с Windows Performance Toolkit стоит ознакомиться более подробно и не в рамках этой статьи.

Оптимизируем процесс загрузки.

Скачиваем веб инсталлятор по ссылке с официального сайта Microsoft — перейти

Либо с данного сайта — скачать

Запускаем файл winsdk_web.exe

В появившемся окне нажимаем Next

Принимаем лицензионное соглашение выставлением пункта I Agree и нажатием кнопки Next
Если есть желание можем изменить путь установки пакета, если нет — нажимаем кнопку Next
Нам нужен всего один пункт, поэтому снимаем галочки с других пунктов и оставляем только Windows Performance Toolkit, нажимаем Next
Все готово к началу загрузки с веб узла Microsoft, нажимаем Next
Ожидаем окончания процесса закачки и появления следующего окна Installation Complete, снимаем галочку — View the Windows SDK Release Notes и нажимаем Finish.

Внимание: Если у вас выдало сообщение об ошибке — Installation Failed — решение проблемы в этой статье.

Запускаем командную строку или меню Выполнить (Сочетание клавиш Windows + R).

Нажимаем ОК

Система предупреждает о перезагрузке, соглашаемся.

После перезагрузки у нас появляется окно Delaying for system preparation (run 1 of 6)

Цифра 1 означает первый проход оптимизации из шести, после каждого прохода, система будет перезагружен автоматически.

Так же Windows Performance Toolkit ожидает 120 секунд, ожидая загрузки программ, запускаемых при старте системы.

После шестой перезагрузки, даже без секундомера можно заметить уменьшение времени требуемого для загрузки Windows 7.

[nx_heading style=»coloredline» heading_tag=»h4″ size=»24″ align=»left»]От автора:[/nx_heading]

Если проблема решена, один из способов сказать «Спасибо» автору — здесь.

Если же проблему разрешить не удалось и появились дополнительные вопросы, задать их можно на нашем форуме, в специальном разделе.

Источник

Модернизация приложений

В предыдущих частях данной статьи мы познакомились с техникой, позволяющей избежать утечек памяти, предотвратить зависание приложений, обсудили использование механизмов 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

Базовые операции по сбору информации используют подсистему протоколирования событий на уровне ядра операционной системы. Для того чтобы узнать, какие провайдеры (поставщики информации) доступны для данной версии операционной системы, можно выполнить следующую команду (здесь и далее применяется интерфейс командной строки с повышенными привилегиями: при вызове CMD. EXE необходимо нажать правую кнопку мыши и выполнить команду Run as Administrator):

Сокращенный результат выполнения данной команды показан на рис. 2.

Рис. 2. Получение списка провайдеров

Как видно из рис. 2, операционная система предоставляет большое число (порядка тысячи) провайдеров информации для различных подсистем, использование которых позволяет собирать и анализировать различные аспекты работы как самой системы, так и процессов и приложений, выполняемых под ее управлением.

Для получения списка провайдеров информации только на уровне ядра (Kernel Mode Providers) можно выполнить следующую команду:

C:\>xperf –providers K

Результат выполнения данной команды показан на рис. 3.

Рис. 3. Получение списка Kernel Mode Providers

Флаги (Kernel Flags) отвечают за сбор информации об отдельных группах операций — например создание и удаление процессов, операции ввода­вывода и т.п. Группы (Kernel Groups) включают комбинации флагов и используются для анализа работы определенных подсистем. Для нашего первого эксперимента с утилитой XPerf мы выберем группу DiagEasy, которая содержит следующие флаги:

Описание этих флагов показано в таблице.

Выполним следующую команду для протоколирования событий на уровне ETW:

C:\>xperf –on DiagEasy

Запустим, например, Internet Explorer и откроем в нем какой­нибудь сайт. После этого завершим протоколирование с помощью команды:

Выполнение данной команды займет некоторое время (порядка 1-2 мин), так как системе требуется объединить данные, собранные ETW, с метаданными и другой информацией и сформировать соответствующий файл — в нашем примере это trace.etl. Теперь выполним команду:

В результате откроется окно Windows Performance Analyzer — утилиты для визуального анализа результатов, собранных с помощью утилиты XPerf. Аналогичный результат можно получить, выполнив команду:

Утилита 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), содержащая числовую информацию, на основе которой был построен тот или иной график.

Давайте обсудим, что мы узнали из приведенного выше примера:

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. Вот пример команды, устанавливающей значение этой переменной (команда должна быть введена одной строкой):

Адрес сайта, указанный в приведенной выше команде, — это «сервер символов» компании Microsoft. Адрес локальной папки, помещенный между символами «*», указывает на локальное хранилище символов, куда будут помещены загруженные с сервера символы.

При анализе собственных приложений также необходимо указать местоположение PDB-файлов для конкретного приложения. Адрес локальной/удаленной папки добавляется к приведенной выше команде set через разделитель «;»:

После того как мы научились загружать символы и указывать их местоположение, давайте посмотрим на визуализацию стека в действии. Для этого выполним следующую команду (команда должна быть введена одной строкой):

C:\>xperf –on PROC_THREAD+LOADER+INTERRUPT+DPC+PROFILE

Затем запустим интересующее нас приложение, выполним в нем необходимые операции и завершим сессию сбора информации командой:

После этого, как и в предыдущем примере, запустим Windows Performance Analyzer для визуального анализа собранной информации:

Визуализация стека включается на графике CPU Sampling by Process. Первая операция — это выполнение команды Load Symbols (в случае загрузки символьной информации с сервера выполнение этой команды может занять некоторое время), затем — команды Summary Table. В отдельном окне будут показаны результаты вызова функций — в данной версии XPerf поддерживается до 16 уровней вложенности.

Обратите внимание на возможность просмотра внутренних и внешних вызовов для каждой функции: после выбора интересующей функции необходимо нажать правую кнопку мыши и выбрать команду Callers или Callees и соответственно команду Innermost или Outermost. Данные для каждой команды будут отображены в отдельном окне, что удобно при анализе цепочек вызова внутри или вне определенной группы функций — как ядра операционной системы, так и анализируемого приложения.

Колонка %Weight указывает вызовы функций, на которые приходилось больше всего времени из всего времени работы данного процесса или приложения. Это более информативно, чем статическое профилирование с указанием времени работы каждой функции, так как в данном случае мы видим еще и цепочку вызовов функций (рис. 8).

Рис. 8. Визуализация стека

Еще одна интересная возможность — это анализ не всего стека вызовов, а только той его части, которая, например, занимала больше всего ресурсов. Для этого на графике CPU Sampling by Process необходимо выбрать интересующий нас временной период и перестроить для него таблицу вызовов с помощью команды Summary Table. Также отметим, что для сравнения можно выбрать несколько интервалов и анализировать их в одновременно открытых окнах.

Использование символьной информации для визуализации стека вызовов является мощным средством анализа работы процессов и приложения. Вот несколько рекомендаций по успешному применению этой возможности:

C:\>xperf –help symbols

убедитесь в том, что правильно установлено значение переменной среды:_NT_SYMBOL_PATH;

важно, чтобы символы для компонентов операционной системы и приложения относились именно к установленной на компьютере версии. Для проверки используйте утилиту symchk.exe из набора утилит Debugging Tools for Windows:

для проверки соответствия двоичных файлов установленным на компьютере символам применяйте утилиту fc:

всегда указывайте, как минимум, флаги PROC_THREAD+LOADER — они позволяют собрать базовую информацию о жизненном цикле процесса и виртуальных адресах загрузки образов в память. Это нужно для того, чтобы убедиться в том, что события, связанные с процессами: Create, Delete, Start Rundown, End Rundown и образами Load, Unload, Start Rundown, End Rundown, присутствуют в таблице, получаемой с помощью следующей команды:

Результат выполнения данной команды показан на рис. 9.

Источник