Анализ загрузки ЦП

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

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

Методы, описанные в этом руководстве, используют windows Анализатор производительности (WPA) из набора средств производительности Windows (WPT). WPT является частью пакета средств оценки и развертывания Windows (Windows ADK), и его можно скачать из программы предварительной оценки Windows. Дополнительные сведения см . в техническом справочнике по Набору средств производительности Windows.

Это руководство организовано в следующих трех разделах:

Основные сведения	В этом разделе описывается управление ресурсами ЦП в Windows 10.
Средства Windows ADK	В этом разделе объясняется, как просматривать и интерпретировать сведения о ЦП в наборе средств Windows ADK.
Techniques	В этом разделе содержится коллекция методов, которые можно использовать для изучения и решения распространенных проблем, связанных с производительностью ЦП.

Фон

В этом разделе содержатся простые описания и основное обсуждение производительности ЦП. Для более комплексного изучения этой темы мы рекомендуем книгу Windows Internals, Fifth Edition.

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

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

Windows 10 активно управляет оборудованием процессора двумя основными способами: управление питанием, балансировка потребления энергии и производительности; и использование, чтобы сбалансировать требования к обработке программ и драйверов.

Управление питанием процессора

Процессоры не всегда существуют в операционном состоянии. Если инструкции не готовы к выполнению, Windows помещает процессор в целевое состояние простоя (или C-State), как определено Windows Power Manager. На основе шаблонов использования ЦП целевое состояние C процессора будет скорректировано с течением времени.

Состояния простоя — это нумерованные состояния из C0 (активные, а не простои) через постепенно низкое число состояний питания. К таким состояниям относятся C1 (остановлено, но часы по-прежнему включены), C2 (остановлены и часы отключены) и т. д. Реализация состояний простоя зависит от процессора. Однако более высокий номер состояния во всех процессорах отражает более низкое потребление энергии, но и более длительное время ожидания, прежде чем процессор сможет вернуться к обработке инструкций. Время, затраченное на бездействующее состояние, значительно влияет на использование энергии и время работы батареи.

Некоторые процессоры могут работать в состоянии производительности (P-) и регулирования (T-), даже если они активно обрабатывают инструкции. P-состояния определяют частоты часов и уровни напряжения, поддерживаемые процессором. T-состояния не изменяют частоту часов напрямую, но могут снизить эффективную скорость часов, пропуская действия обработки на некоторых долях часов. Вместе текущие состояния P- и T определяют эффективную частоту работы процессора. Более низкие частоты соответствуют снижению производительности и снижению потребления электроэнергии.

Windows Power Manager определяет соответствующее состояние P-и T для каждого процессора на основе шаблонов использования ЦП и системной политики питания. Время, затраченное в состояниях высокой производительности и состояния низкой производительности, значительно влияет на использование энергии и время работы батареи.

Управление использованием процессора

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

• Процессы

• Потоки

• Отложенные вызовы процедур (DPCs) и подпрограммы службы прерываний (ISR)

Процессы и потоки

Все программы в пользовательском режиме в Windows выполняются в контексте процесса. Процесс включает следующие атрибуты и компоненты:

• Виртуальное адресное пространство

• Класс priority

• Загруженные модули программы

• Сведения о среде и конфигурации

• По крайней мере один поток

Хотя процессы содержат модули программы, контекст и среду, они не запланированы непосредственно на выполнение на процессоре. Вместо этого потоки, принадлежащие процессу, должны выполняться на процессоре.

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

Так как количество процессоров в системе ограничено, все потоки нельзя запускать одновременно. Windows реализует общий доступ к времени процессора, который позволяет потоку выполняться в течение определенного периода времени, прежде чем процессор переключается на другой поток. Действие переключения между потоками называется параметром контекста и выполняется компонентом Windows, который называется диспетчером. Диспетчер принимает решения о планировании потоков на основе приоритета, идеального процессора и сопоставления, квантового и состояния.

Приоритет

Приоритет является ключевым фактором в том, как диспетчер выбирает поток для выполнения. Приоритет потока — целое число от 0 до 31. Если поток является исполняемым и имеет более высокий приоритет, чем текущий поток, то поток с более низким приоритетом сразу же преумножается, и поток с более высоким приоритетом переключается в контексте.

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

Идеальный процессор и сходство

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

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

Quantum

Контекстные коммутаторы являются дорогостоящими операциями. Windows обычно позволяет каждому потоку выполняться в течение определенного периода времени, который называется квантовым , прежде чем переключаться на другой поток. Квантовая длительность предназначена для сохранения видимой скорости реагирования системы. Она обеспечивает максимальную пропускную способность, минимизируя затраты на переключение контекста. Длительность квантовых вычислений может различаться между клиентами и серверами. Квантовые длительность обычно длиннее на сервере, чтобы максимально увеличить пропускную способность за счет видимой скорости реагирования. На клиентских компьютерах Windows назначает более короткие квантовые общей сложности, но предоставляет более длинный квантовый поток, связанный с текущим окном переднего плана.

Штат

Каждый поток существует в определенном состоянии выполнения в любое время. Windows использует три состояния, относящиеся к производительности; это: Выполнение, готовность и ожидание.

Потоки, которые в настоящее время выполняются, находятся в состоянии выполнения . Потоки, которые могут выполняться, но в настоящее время не выполняются в состоянии "Готово ". Потоки, которые не могут выполняться, так как они ожидают определенного события, находятся в состоянии ожидания .

Переход состояния к состоянию показан на рисунке 1.

Рис. 1. Переходы состояния потока

Рисунок 1. Переходы состояния потока описаны следующим образом:

1. Поток в состоянии выполнения инициирует переход к состоянию ожидания путем вызова функции ожидания, например WaitForSingleObject или Sleep(> 0).

2. Выполняющаяся операция потока или ядра считывает поток в состоянии ожидания (например, SetEvent или таймер истечения срока действия). Если процессор неактивен или если готовый поток имеет более высокий приоритет, чем текущий запущенный поток, то легкодоступный поток может переключиться непосредственно в состояние "Выполнение". В противном случае он помещается в состояние "Готово".

3. Поток в состоянии "Готово" планируется для обработки диспетчером при ожидании запущенного потока, получения (спящего(0)) или окончания его квантового вычисления.

4. Поток в состоянии "Выполнение" переключается и помещается в состояние готовности диспетчером, когда он преумножается потоком с более высоким приоритетом, выдает (Спящий(0)) или когда его квантовые концы.

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

ЦП и isR

Помимо обработки потоков процессоры реагируют на уведомления от аппаратных устройств, таких как сетевые карты или таймеры. Если аппаратное устройство требует внимания процессора, оно создает прерывание. Windows реагирует на аппаратное прерывание, приостанавливая текущий поток и выполняя ISR, связанный с прерыванием.

Во время выполнения ISR обработчик может быть запрещен обрабатывать любые другие действия, включая другие прерывания. По этой причине службы ISR должны быстро завершить работу или производительность системы может снизиться. Чтобы уменьшить время выполнения, службы ISR обычно планируют выполнять работу, которая должна выполняться в ответ на прерывание. Для каждого логического процессора Windows поддерживает очередь запланированных ЦП. DPCs принимают приоритет над потоками на любом уровне приоритета. Перед возвратом процессора к потокам обработки он выполняет все ЦП в очереди.

В течение времени, когда процессор выполняет ЦП и isR, потоки не могут выполняться на этом процессоре. Это свойство может привести к проблемам для потоков, которые должны выполнять работу с определенной пропускной способностью или с точным временем, например поток, который воспроизводит звук или видео. Если время процессора, используемое для выполнения ЦП и ISR, предотвращает получение этих потоков достаточного времени обработки, поток может не достичь требуемой пропускной способности или завершить рабочие элементы вовремя.

Средства Windows ADK

Windows ADK записывает сведения о оборудовании и оценки в файлы результатов оценки. WPA предоставляет подробные сведения об использовании ЦП в различных графах. В этом разделе объясняется, как использовать Windows ADK и WPA для сбора, просмотра и анализа данных о производительности ЦП.

Файлы результатов оценки Windows ADK

Так как Windows поддерживает только симметричные многопроцессорные системы, все сведения в этом разделе применяются ко всем установленным ЦП и ядрам.

Подробные сведения о оборудовании ЦП доступны в EcoSysInfo разделе файлов результатов оценки на <Processor><Instance id=”0”> узле.

Например:

<Processor>
  <Instance id="0">
    <ProcessorName>The name of the first CPU</ProcessorName>
    <TSCFrequency>The maximum frequency of the first CPU</TSCFrequency>
    <NumProcs>The total number of processors</NumProcs>
    <NumCores>The total number of cores</NumCores>
    <NumCPUs>The total number of logical processors</NumCPUs>
    ...and so on...

Графы WPA

После загрузки трассировки в WPA можно найти сведения о оборудовании процессора в разделах Trace/System Configuration/General and Trace/System Configuration/PnP пользовательского интерфейса WPA.

Обратите внимание на все процедуры, описанные в этом руководстве, в WPA.

Граф состояний простоя ЦП

Если данные о состоянии простоя собираются в трассировке, граф состояний простоя ЦП будет отображаться в пользовательском интерфейсе WPA. Этот граф всегда содержит данные о состоянии простоя целевого объекта для каждого процессора. Граф также будет содержать сведения о фактическом состоянии простоя каждого процессора, если это состояние поддерживается обработчиком.

Каждая строка в следующей таблице описывает изменение состояния простоя для целевого или фактического состояния процессора. Для каждой строки в графе доступны следующие столбцы:

Column	Сведения
ЦП	Процессор, затронутый изменением состояния.
Время ввода	Время, когда обработчик вошел в состояние простоя.
Время выхода	Время выхода процессора из состояния простоя.
Max:Duration(ms)	Время, затраченное в состоянии простоя (по умолчанию агрегирование:максимум).
Min:Duration(ms)	Время, затраченное в состоянии простоя (по умолчанию агрегирование:минимум).
Следующее состояние	Состояние, в которое процессор переходит после текущего состояния.
Состояние prev	Состояние, из которого процессор перешло до текущего состояния.
Штат	Текущее состояние простоя.
Состояние (числовой)	Текущее состояние простоя в виде числа (например, 0 для C0).
Sum:Duration(ms)	Время, затраченное в состоянии простоя (агрегирование по умолчанию:sum).
Таблица	Неиспользуемые
Тип	Целевой объект (для выбранного целевого состояния Power Manager для процессора) или Фактический (для фактического состояния простоя процессора).

Профиль WPA по умолчанию предоставляет два предустановки для этого графа: состояние по типу, ЦП и схеме состояний по типу, ЦП.

Состояние по типу, ЦП

Целевые и фактические состояния каждого ЦП графируются вместе с номером состояния на оси Y в состоянии по типу , графУ ЦП . Рис. 2 Состояние состояния простоя ЦП по типу, ЦП показывает фактическое состояние ЦП, так как оно изменяется между активными и целевыми состояниями простоя.

Рис. 2 Состояние состояния простоя ЦП по типу, ЦП

Схема состояния по типу, ЦП

На этом графике целевые и фактические состояния каждого ЦП представлены в формате временной шкалы. Каждое состояние имеет отдельную строку на временной шкале. Рис. 3 Схема состояния состояния простоя ЦП по типу, ЦП отображает те же данные, что и состояние состояния простоя ЦП по типу, ЦП в представлении временной шкалы.

Рис. 3 Диаграмма состояния состояния простоя ЦП по типу, ЦП

График частоты ЦП

Если данные частоты ЦП были собраны в системе, поддерживающей несколько состояний P-или T, граф частоты ЦП будет доступен в пользовательском интерфейсе WPA. Каждая строка в следующей таблице представляет время на определенном уровне частоты процессора. Столбец частоты (МГц) содержит ограниченное количество частот, которые соответствуют состояниям P и T-состояниям, поддерживаемым процессором. Для каждой строки в графе доступны следующие столбцы:

Column	Сведения
% длительность	Длительность выражается в процентах от общего времени ЦП за текущий видимый период времени.
Count	Количество изменений частоты (всегда 1 для отдельных строк).
ЦП	ЦП, затронутый изменением частоты.
Время ввода	Время ввода ЦП в состояние P.
Время выхода	Время выхода ЦП из состояния P..
Частота (МГц)	Частота ЦП в течение времени, когда она находится в состоянии P.
Max:Duration(ms)	Время, затраченное на состояние P (агрегирование по умолчанию:максимум).
Min:Duration(ms)	Время, затраченное на состояние P (агрегирование по умолчанию:минимум).
Sum:Duration(ms)	Время, затраченное на P-состояние (агрегирование по умолчанию:sum).
Таблица	Неиспользуемые
Тип	Дополнительные сведения о P-State.

Профиль по умолчанию определяет частоту по предустановкам ЦП для этого графа. Рис. 4 Частота ЦП по ЦП показывает ЦП по мере перехода между тремя состояниями P:

Рис. 4 Частота ЦП по ЦП

Граф использования ЦП (пример)

Данные, отображаемые на графе использования ЦП (выборка), представляют примеры действий ЦП, которые выполняются с регулярным интервалом выборки. В большинстве трассировок это один миллисекунда (1 мс). Каждая строка в таблице представляет один пример.

Вес образца представляет значение этого примера относительно других выборок. Вес равен метке времени текущего примера минус метка времени предыдущего примера. Вес не всегда равен интервалу выборки из-за колебаний состояния системы и активности.

Рис. 5 Выборка ЦП представляет способ сбора данных:

Рис. 5 Выборка ЦП

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

Для каждой строки в графе доступны следующие столбцы:

Column	Сведения
% вес	Вес выражается в процентах от общего времени ЦП, затраченного на текущий видимый диапазон времени.
Адрес	Адрес памяти функции, которая находится в верхней части стека.
Все счетчики	Количество примеров, представленных строкой. Это число включает примеры, которые выполняются при простое процессора. Для отдельных строк этот столбец всегда равен 1.
Count	Количество примеров, представленных строкой, за исключением примеров, которые выполняются при простое процессора. Для отдельных строк этот столбец всегда равен 1 (или 0, если ЦП находился в состоянии низкой мощности).
ЦП	0-й индекс ЦП, на котором был взят этот пример.
Отображаемое имя.	Отображаемое имя активного процесса.
DPC/ISR	Выборка измеряла регулярное использование ЦП, DPC/ISR или низкое состояние питания.
Function	Функция в верхней части стека.
Модуль	Модуль, содержащий функцию в верхней части стека.
Приоритет	Приоритет выполняющегося потока.
Процедура	Имя образа процесса, которому принадлежит запущенный код.
Имя процесса	Полное имя (включая идентификатор процесса) процесса, который владеет запущенным кодом.
Стек	Стек выполняющегося потока.
Идентификатор потока	Идентификатор выполняющегося потока.
Функция запуска потока	Функция, с которой запускается запущенный поток.
Модуль запуска потока	Модуль, содержащий функцию запуска потока.
TimeStamp	Время, затраченного на выборку.
Вес	Время (в миллисекундах), представленное примером (т. е. временем последнего примера).

Профиль по умолчанию предоставляет следующие предустановки для этого графа:

• Использование ЦП

• Использование по приоритету

• Использование по процессу

• Использование по процессу и потоку

Использование ЦП

Использование ЦП по диаграмме ЦП показывает, как работа распределяется между процессорами. На рис. 6 Загрузка ЦП по ЦП показывает это распределение для двух ЦП:

Рис. 6 Использование ЦП по ЦП

Использование по приоритету

Использование ЦП, сгруппированного по приоритету потока, показывает, как высокоприоритетные потоки влияют на потоки с низким приоритетом. Рис. 7 Использование ЦП (пример) по приоритету отображает этот граф:

Рис. 7 Использование ЦП (пример) по приоритету

Использование по процессу

Использование ЦП, сгруппированного по процессу, показывает относительное использование процессов. На рисунке 8 .Использование ЦП (пример) по процессу показано это предварительное определение. В этом примере графа показано, что один процесс потребляет больше времени ЦП, чем другие процессы.

Рис. 8 Использование ЦП (пример) по процессу

Использование по процессу и потоку

Использование ЦП, сгруппированное по процессу, а затем сгруппированное по потоку, показывает относительное использование процессов и потоков в каждом процессе. На рисунке 9 Загрузка ЦП (пример) по процессу и потоку показана эта предустановка. Потоки одного процесса выбираются в этом графе.

Рис. 9 Использование ЦП (пример) по процессу и потоку

График использования ЦП (точный)

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

1. Новый поток выключается.

2. Новый поток готов к выполнению потоком подготовки.

3. Новый поток переключается, тем самым переключяя старый поток.

4. Новый поток снова выключается.

На рисунке 10 точную схему использования ЦП время поступает слева направо. Метки схемы соответствуют именам столбцов в графе "Использование ЦП" (точно). Метки для столбцов метки времени отображаются в верхней части диаграммы, а метки для столбцов длительности интервала отображаются в нижней части схемы.

Рис. 10 Схема точного использования ЦП

Разрывы временной шкалы на рис. 10 Схема точного использования ЦП делят временную шкалу на регионы, которые могут происходить одновременно на разных ЦП. Эти временные шкалы могут перекрываться до тех пор, пока порядок нумерованных событий не изменяется. Например, поток готовности может выполняться в процессоре-2 одновременно, когда новый поток переключается, а затем обратно в процессор-1).

Сведения записываются для следующих четырех целевых объектов на временной шкале:

• Новый поток, который был переключен. Основной фокус этой строки в графе.

• Поток NewPrev, который относится к предыдущему времени, в котором был переключен новый поток.

• Готовый поток, который является потоком, который подготовил новый поток для обработки.

• Старый поток, который был переключен при переключении нового потока.

Данные в следующей таблице относятся к каждому целевому потоку:

Column	Сведения
% использования ЦП	Использование ЦП нового потока после переключения. Это значение выражается в процентах от общего времени ЦП за текущий видимый период времени.
Count	Количество параметров контекста, представленных строкой. Это всегда 1 для отдельных строк.
Count:Waits	Количество ожиданий, представленных строкой. Это всегда 1 для отдельных строк, за исключением случаев, когда поток переключается в состояние простоя; В этом случае для него задано значение 0.
ЦП	ЦП, на котором произошел переключение контекста.
Использование ЦП (мс)	Использование ЦП нового потока после переключения контекста. Это равно NewInSwitchTime, но отображается в миллисекундах.
IdealCpu	Идеальный ЦП, выбранный планировщиком для нового потока.
LastSwitchOutTime (s)	Предыдущее время отключения нового потока.
NewInPri	Приоритет нового потока, который переключается.
NewInSwitchTime(s)	NextSwitchOutTime(s) минус SwitchInTime(s)
NewOutPri	Приоритет нового потока при переключениях.
NewPrevOutPri	Приоритет нового потока, когда он был переключлен ранее.
NewPrevState	Состояние нового потока после того, как он был ранее отключен.
NewPrevWaitMode	Режим ожидания нового потока, когда он был выключен ранее.
NewPrevWaitReason	Причина отключения нового потока.
NewPriDecr	Повышение приоритета, влияющее на поток.
NewProcess	Процесс нового потока.
Имя NewProcess	Имя процесса нового потока, включая PID.
NewQnt	Не используется.
NewState	Состояние нового потока после его переключения.
NewThreadId	Идентификатор потока нового потока.
NewThreadStack	Стек нового потока при переключении.
NewThreadStartFunction	Начальная функция нового потока.
NewThreadStartModule	Начальный модуль нового потока.
NewWaitMode	Режим ожидания нового потока.
NewWaitReason	Причина отключения нового потока.
NextSwitchOutTime(s)	Время, когда новый поток был переключлен.
OldInSwitchTime(s)	Время, когда старый поток был переключлен до его отключения.
OldOutPri	Приоритет старого потока при переключении.
OldProcess	Процесс, принадлежащий старому потоку.
Имя OldProcess	Имя процесса, который владеет старым потоком, включая PID.
OldQnt	Не используется.
OldState	Состояние старого потока после отключения.
OldThreadId	Идентификатор потока старого потока.
OldThreadStartFunction	Начальная функция старого потока.
OldThreadStartModule	Начальный модуль старого потока.
OldWaitMode	Режим ожидания старого потока.
OldWaitReason	Причина отключения старого потока.
PrevCState	Предыдущий CState процессора. Если это не равно 0 (активно), процессор был в состоянии простоя до переключения нового потока в контекст.
Ready(s)	SwitchInTime(s) минусReadyTime (s)
Подготовка ThreadId	Идентификатор потока подготовки.
Подготовка ThreadStartFunction	Начальная функция готового потока.
Подготовка ThreadStartModule	Начальный модуль готового потока.
ReadyingProcess	Процесс, который владеет готовым потоком.
Имя readyingProcess	Имя процесса, который владеет готовым потоком, включая PID.
ReadyThreadStack	Стек готового потока.
ReadyTime (s)	Время, когда новый поток был готов.
SwitchInTime(s)	Время переключения нового потока.
TimeSinceLast (s)	SwitchInTime(s) минус LastSwitchOutTime (s)
Ожидание (s)	ReadyTime (s) минус LastSwitchOutTime (s)

Профиль по умолчанию использует следующие предустановки для этого графа:

• Временная шкала по ЦП

• Временная шкала по процессу, потоку

• Использование по приоритету при начале переключения контекста

• Использование ЦП

• Использование по процессу, потоку

Временная шкала по ЦП

Использование ЦП на временной шкале ЦП показывает, как работает между процессорами. Рис. 11 Временная шкала использования ЦП (точную) по ЦП отображает временную шкалу в восьмипроцессорной системе:

Рис. 11 Временная шкала использования ЦП (точную) по ЦП

Временная шкала по процессу, потоку

Использование ЦП на временной шкале для каждого процесса на каждом потоке показывает, какие процессы выполняются в определенное время. Рис. 12 Временная шкала использования (точную) по процессу, поток показывает эту временную шкалу в нескольких процессах:

Рис. 12 Временная шкала использования (точную) по процессу, потоку

Использование по приоритету при начале переключения контекста

Этот граф определяет всплески активности потока с высоким приоритетом на каждом уровне приоритета. Рис. 13 Использование ЦП (точное) по приоритету при переключении контекста показывает распределение приоритетов:

Рис. 13 Использование ЦП (точное) по приоритету при переключении контекста

Использование ЦП

На этом графе использование ЦП группируется и графируется ЦП, чтобы показать, как работает работа между процессорами. Рис. 14 Использование ЦП (точное) по ЦП показывает этот график для системы с восемью процессорами.

Рис. 14 Использование ЦП (точное) по ЦП

Использование по процессу, потоку

На этом графе использование ЦП группируется сначала по процессу, а затем по потоку. В нем показано относительное использование процессов и потоков в каждом процессе рис. 15 Использование ЦП (точное) по процессу, поток показывает это распределение между несколькими процессами:

Рис. 15 Использование ЦП (точное) по процессу, потоку

Граф DPC/ISR

Граф DPC/ISR является основным источником данных DPC/ISR в WPA. Каждая строка в графе представляет фрагмент, который является периодом времени, в течение которого DPC или ISR выполнялся непрерывно. Данные собираются в начале и конце фрагментов. При завершении DPC/ISR собираются дополнительные данные. Рис. 16 Схема DPC/ISR показывает, как это работает:

Рис. 16 Схема DPC/ISR

Рис. 16 Схема DPC/ISR описывает данные, собранные во время следующих действий:

1. DPC/ISR-A запускается.

2. Прерывание устройства с более высоким уровнем прерывания, чем DPC/ISR-A, приводит к прерыванию DPC/ISR A, тем самым заканчивая первый фрагмент DPC/ISR-A.

3. ISR-B завершается и тем самым заканчивает фрагмент ISR-B. DPC/ISR-A возобновляет выполнение во втором фрагменте.

4. DPC/ISR-A завершается, тем самым заканчивая второй фрагмент DPC/ISR-A.

Строка для каждого фрагмента отображается в таблице данных. Фрагменты для DPC/ISR-A используют идентичные сведения с столбцами, не относящихся к фрагментам.

Столбцы графа DPC/ISR описывают сведения о уровне фрагмента или столбцы уровня DPC/ISR. Каждый фрагмент разнородных данных в столбцах уровня фрагмента и идентичных данных в столбцах DPC/ISR.

Column	Сведения
% длительность (фрагментированная)	Длительность (фрагментированная), выраженная в процентах от общего времени ЦП в течение текущего видимого периода времени.
% эксклюзивной длительности	Эксклюзивная длительность, выраженная в процентах от общего времени ЦП в течение текущего видимого периода времени.
% инклюзивной длительности	Инклюзивное время, которое выражается в процентах от общего времени ЦП в течение текущего видимого периода времени.
Адрес	Адрес памяти функции DPC или ISR.
Count (DPCs/ISR)	Количество ЦП/ISR, представленных этой строкой. Это всегда 1 для строк, представляющих окончательный фрагмент DPC/ISR; в противном случае это число равно 0.
Число (фрагменты)	Количество фрагментов, представленных строкой. Это всегда 1 для отдельных строк.
ЦП	Индекс логического процессора, на котором запущен DPC или ISR.
Тип DPC	Для DPC тип DPC — обычный или таймер. Это значение пусто для ISR.
Время ввода DPC/ISR	Время трассировки при запуске DPC/ISR.
Время выхода DPC/ISR	Время от начала трассировки до завершения DPC/ISR.
Длительность (фрагментированные) (мс)	Время выхода фрагмента (s) минус время ввода фрагмента в миллисекундах.
Эксклюзивная длительность (мс)	Сумма фрагментированных длительности в мс. для всех фрагментов этого DPC/ISR.
Фрагмент	Если DPC/ISR этой строки содержит несколько фрагментов, это значение равно True; в противном случае — false.
Фрагмент	Если это не единственный фрагмент для этого DPC/ISR, это значение равно True; в противном случае — false.
Время ввода фрагмента (s)	Время запуска фрагмента.
Время выхода фрагмента (s)	Время остановки выполнения фрагмента.
Function	Запущенная функция DPC или ISR.
Включаемая длительность (мс)	DPC/ISR Exit Time (s) минус DPC/ISR Enter Time (s) в миллисекундах.
MessageIndex	Индекс прерываний для прерываний, сигнализованных сообщением.
Модуль	Модуль, содержащий функцию DPC или ISR.
Возвращаемое значение	Возвращаемое значение DPC/ISR
Тип	Тип события; это — DPC или прерывание (ISR).
Вектор	Значение вектора прерывания на устройстве.

Профиль по умолчанию использует следующие предустановки для этого графа:

• [DPC,ISR,DPC/ISR] Длительность по ЦП

• [DPC,ISR,DPC/ISR] Длительность по модулю, функции

• [DPC,ISR,DPC/ISR] Временная шкала по модулю, функции

[DPC,ISR,DPC/ISR] Длительность по ЦП

События DPC/ISR агрегируются ЦП, на котором они выполняются и сортируются по длительности. На этом графе показано выделение активности DPC между ЦП. На рисунке 17 DPC/ISR Длительность ЦП показан этот график для системы с восемью процессорами.

Рис. 17 Длительность DPC/ISR по ЦП

[DPC,ISR,DPC/ISR] Длительность по модулю, функции

События DPC/ISR агрегируются в этом графе модулем и функцией подпрограмм DPC/ISR и сортируются по длительности. В этом разделе показано, какие подпрограммы DPC/ISR потребляют большую часть времени на 18 DPC/ISR Duration by Module, Function показывает период времени, который вызывает действие DPC/ISR в двух модулях:

Рис. 18 DPC/ISR Duration by Module, Function

[DPC,ISR,DPC/ISR] Временная шкала по модулю, функции

События DPC/ISR агрегируются в этом графе модулем и функцией подпрограмм DPC/ISR. Они графируются как временная шкала. На этом графике представлено подробное представление периода времени, в течение которого выполнялись ЦП/ISR. Этот граф также может показать, как можно фрагментировать один DPC/ISR. Рисунок 19 DPC/ISR Временной шкалы по модулю, функция показывает временную шкалу действий в трех модулях:

Рис. 19 DPC/ISR Временной шкалы по модулю, функции

Деревья стека

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

Рис. 20 стеков из трех событий

Рис. 21 Общие сегменты, определяемые способом определения общих последовательностей для этого графа:

Рис. 21 Общие сегменты, определенные

Рис. 22 Дерево, созданное из стеков, показывает, как общие сегменты объединяются для формирования узлов дерева:

Рис. 22 Дерево, созданное из стеков

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

5ms   ModuleA!Function1
5ms   ModuleA!Function2
5ms   ModuleA!Function3
      |
4ms   |-ModuleA!Function4
4ms   |   ModuleB!Function1
|   |
1ms   |   |-ModuleB-Function2
1ms   |   |    ModuleB-Function3
|   |
3ms   |   |-ModuleB!Function3
3ms   |        ModuleB!Function4
      |
1ms   |-ModuleA!Function5
1ms        ModuleC!Function1
1ms        ModuleC!Function2

Узел <itself> в стеке представляет время, когда сама функция находится в верхней части стека. Узел <itself> не включает время, затраченное на функции, вызываемые родительской функцией. Эта длительность называется эксклюзивным временем, потраченным в функции.

Например, Функция1 вызывает Function2. Функция2 провела 2 мс в цикле с интенсивным ЦП и вызвала другую функцию, которая выполнялась для 4 мс. Это может быть представлено следующим стеком:

6ms   ModuleA!Function1
      |
2ms   |-<itself>
4ms   |-ModuleA!Function2
4ms        ModuleB!Function3
4ms        ModuleB-Function4

Методы

В этом разделе описывается стандартный подход к анализу производительности. Он предоставляет методы, которые можно использовать для изучения распространенных проблем производительности, связанных с ЦП.

Анализ производительности — это четырехэтапный процесс:

1. Определите сценарий и проблему.

2. Определите компоненты, участвующие и соответствующий диапазон времени.

3. Создайте модель того, что должно было произойти.

4. Используйте модель для выявления проблем и изучения первопричин.

Определение сценария и проблемы

Первым шагом в анализе производительности является четкое определение сценария и проблемы. Многие проблемы с производительностью влияют на сценарии, измеряемые метриками оценки. Например:

Сценарий 1. Физический ресурс не используется полностью. Например, сервер не может полностью использовать сетевое подключение, так как он не может быстро шифровать пакеты.

Сценарий 2. Физический ресурс используется больше, чем должно быть. Например, система использует значительные ресурсы ЦП во время простоя, использующего питание от батареи.

Сценарий 3. Действия не выполняются по требуемой ставке. Например, кадры удаляются во время воспроизведения видео, так как кадры не декодируются достаточно быстро.

Сценарий 4. Действие было отложено. Например, пользователь запустил Internet Explorer, но потребовалось больше времени, чем ожидалось, чтобы открыть вкладку.

Сценарии 3 и 4, связанные с ресурсами ЦП, рассматриваются в этом руководстве. Сценарии 1 и 2 не охватываются. Чтобы проанализировать эти проблемы, можно начать с неоднозначного наблюдения, например "слишком медленно" и задать дополнительные вопросы, чтобы определить сценарий и точную проблему.

Определение компонентов и периода времени

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

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

Создание модели

Чтобы понять первопричины проблемы, необходимо иметь модель того, что должно произойти. Модель начинается с проблемы или любой связанной цели для метрики; Например, "Эта операция должна завершиться менее чем за 5 секунд".

Более полная модель содержит сведения о том, как должны выполняться компоненты. Например, какое взаимодействие ожидается между компонентами? Какое использование ресурсов является типичным? Сколько времени обычно занимает операции?

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

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

После создания модели можно сравнить трассировку с моделью для выявления проблем. Например, модель для определенного действия с именем "Приостановка устройств" может предложить, что все действия должны выполняться в три секунды , в то время как каждый экземпляр вложенного действия с именем "Приостановка <устройства> " должен занять не более 100 мс. Если два экземпляра вложенного действия Приостановка <имени> устройства принимают 800 мс, следует изучить эти экземпляры.

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

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

Интерференция потока: поток не получил достаточно времени выполнения, так как другие потоки выполнялись вместо этого. В этом случае поток считается голодным или упрещенным.

Вмешательство DPC/ISR: потоки не получили достаточно времени выполнения, так как ЦП были заняты обработкой DPCs или ISR.

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

Расширенный метод: анализ ожидания и критически важный путь

Действие — это сеть операций, некоторые последовательные и параллельные, которые выполняются с начального события до конечного события. Любая пара событий start/end в трассировке может рассматриваться как действие. Самый длинный путь через эту сеть операций известен как критический путь. Уменьшение длительности любой операции на критическом пути напрямую уменьшает длительность общей активности, хотя она также может изменить критический путь.

На рисунке 23 Операции действий показаны действия трех потоков. Thread-1 отправляет событие запуска действия, а затем ожидает завершения задач Thread-2 и Thread-3. Thread-2 сначала завершает свою задачу, а затем Thread-3. Когда оба потока выполнили свои задачи, Поток-1 будет готов и завершает событие действия.

Рис. 23 Операции с действиями

В этом сценарии критически важный путь включает части Thread-3 и Thread-1. Они трассируются на рис. 24 критически важный путь. Так как Thread-2 не находится на критическом пути, время выполнения задачи не влияет на общее время действия.

Рис. 24 Критический путь

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

Общий подход к поиску критического пути

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

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

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

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

График действий отображается при загрузке трассировки с помощью XML-файла результатов оценки. Чтобы определить процесс и поток, связанные с определенным действием, разверните граф на интересующее действие, а затем переключите представление на Graph+Table. Задайте для режима графа значение Table. Начальный процесс, идентификатор потока запуска, конечный процесс и столбцы идентификатора конечного потока отображаются для каждого действия в таблице.

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

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

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

Процедура: поиск критического пути в WPA

В следующей процедуре предполагается, что вы определили действие в графе действий, для которого требуется найти критически важный путь.

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

2. Добавьте граф использования ЦП (точный). Увеличьте масштаб затронутого действия и примените предустановку "Использование по процессу", "Поток ".

3. Щелкните правой кнопкой мыши заголовки столбцов и сделайте столбцы ReadyThreadStack и ЦП (ms) видимыми. Удалите столбцы Ready (us) [Max] и Waits (us) [Max].

4. Разверните целевой процесс и отсортируйте его соответственно по использованию ЦП (ms),Ready (us) [Sum], и Waits (us) [Sum].

5. Найдите NewThreadIds в процессе, который имеет наибольшее время, затраченное на выполнение, готовность или ожидание.

   Потоки, которые тратят значительное время в состояниях "Выполнение" или "Готово", могут представлять прямое использование ЦП на критическом пути. Обратите внимание, что их идентификаторы потоков.Threads, которые тратят значительное время в состоянии ожидания, могут ожидать ввода-вывода, таймера или другого потока в критическом пути.

6. Чтобы узнать, какие потоки ждали, разверните группу NewThreadId , чтобы отобразить ReadyThreadStack.

7. Разверните узел [root].

8. Стеки, начинающиеся с KiDispatchInterrupt , не связаны с другим потоком. Чтобы определить, что поток ждал в этих стеках, разверните KiDispatchInterrupt и просмотрите функции в дочернем стеке. IopfCompleteRequest указывает, что готовый поток ждал ввода-вывода. KiTimerExpiration указывает, что готовый поток ждал таймера.

9. Разверните стеки, которые не начинаются с KiDispatchInterrupt , пока не увидите readyingProcess и ReadyingThread. Если процесс уже развернут, разверните NewThreadId, соответствующий readyingThreadThread. Повторите этот шаг, пока не найдите поток, который выполняется, готов, ожидает другой причины или ждет другого процесса. Если поток ожидает другого процесса, повторите эту процедуру с помощью этого процесса.

Пример

В этом примере показана задержка в действии init обозревателя быстрого запуска возобновления запуска. Поиск в области "Проблемы" показывает, что для этого действия передаются семь проблем с задержкой. Каждый из этих вопросов можно рассматривать как сегмент критического пути. Определены следующие ключевые сегменты:

• Поток 3872 процесса TestBootStrapper.exe (3024) выполняется в течение 2,1 секунды.

• Поток 3872 процесса TestBootStrapper.exe (3024) использует 1 секунду времени ЦП.

• Поток 3872 процесса TestBootStrapper.exe (3024) очищает куст реестра для 544 миллисекунда.

• Поток 3872 процесса TestBootStrapper.exe (3024) спит в 513 миллисекундах.

• Потоки 4052 и 4036 Explorer.exe считываются с диска, что приводит к задержке в 461 миллисекундах.

• Поток 3872 процесса TestBootStrapper.exe (3024) голодает в 187 миллисекундах.

• Поток 3872 процесса TestBootStrapper.exe записывает на диск 3,5 МБ, что приводит к задержке в 178 миллисекунда.

Проблемы показывают, что это действие было отложено на 5,2 секунды. Эти задержки составляют большую часть деятельности в целом 6,3 секунды. Приложение TestBootStrapper.exe в первую очередь несет ответственность за задержку, в первую очередь потому, что она предопределила другие задачи обработки.

Исследование проблем в критическом пути

1. Увеличьте масштаб в затронутом регионе и добавьте столбцы ReadyThreadStack и ЦП (ms).

2. В этом случае Explorer.exe — это процесс, который завершает действие. Разверните процесс explorer.exe и сортируйте его соответственно по использованию ЦП (ms),Ready (us) [Sum], и Waits (us) [Sum], как показано на следующих рисунках:

   

   Рис. 25 Действие по использованию ЦП (мс)

   

   Рис. 26 Действие готово (мы)

   

   Рис. 27 Действие по ожиданиям (нам)

3. Сортировка по столбцу "Использование ЦП( мс) отображает верхнюю дочернюю строку в 299 миллисекундах. Сортировка по столбцу Ready (us) [Sum] отображает верхнюю дочернюю строку 46 мс. Сортировка по столбцу Waits (us) [Sum] отображает верхнюю дочернюю строку в 5749 миллисекундах и вторую строку в 4902 миллисекундах. Так как эти строки значительно способствуют задержке, их следует изучить дальше.

4. Разверните стеки, чтобы отобразить готовые потоки, как показано на следующих рисунках:

   

   Рис. 28. Процесс подготовки и подготовка потока для потока

   

   Рис. 29. Процесс подготовки и подготовка потока для другого потока

   В этом примере первый поток тратит большую часть времени, ожидая завершения процесса RunOnce.exe. Вы должны изучить, почему процесс RunOnce.exe занимает так много времени для завершения. Второй поток ожидает первого потока и, вероятно, является незначительной связью в той же цепочке ожидания.

5. Повторите действия, описанные в этой процедуре для RunOnce.exe. Основной столбец вкладов — Waits (us) и имеет четыре возможных участника.

6. Разверните каждый участник, чтобы увидеть, что первые три участника ожидают четвертого участника. Эта ситуация делает первые три участника незначительными для цепочки ожидания. Четвертый участник ожидает другого процесса, TestBootStrapper.exe.

   Этот сценарий показан на рисунке 30 "Процесс готовности" и "Подготовка потока для потока" в RunOnce.exe:

   

   Рис. 30 Процесс подготовки и подготовка потока для потока в RunOnce.exe

7. Повторите действия, описанные в этой процедуре для TestBootStrapper.exe. Результаты показаны на следующих трех рисунках:

   

   Рис. 31 Потоки по использованию ЦП (мс)

   

   Рис. 32 Потоки по готовности (нам)

   

   Рис. 33 Потоки по ожиданиям (нам)

   Поток 3872 провел примерно 1 секунду, 2 секунды готовности и 1,3 секунды ожидания. Так как этот поток также является готовым потоком для потока 3872, время выполнения и готовности, вероятно, способствует задержке. Оценка сообщает о следующих проблемах, время которых соответствует задержкам:

   • Поток 3872 процесса TestBootStrapper.exe (3024) преумножен для 2,1 секунды.

   • Поток 3872 процесса TestBootStrapper.exe (3024) голодает в 187 миллисекундах.

   • Поток 3872 процесса TestBootStrapper.exe (3024) использует 1 секунду времени ЦП.

8. Чтобы найти другие проблемы с вкладом, просмотрите событие, для которого ожидается поток 3872. Разверните ReadyThreadStack , чтобы просмотреть участников до 1,3 секунд ожидания, как показано на рис. 34 участника в время ожидания:

   

   Рис. 34 Участника для времени ожидания

   KiRetireDpcList обычно связан с вводом-выводом, а KiTimerExpiration — таймер. Вы можете просмотреть, как были инициированы i/Os и таймер, удалив Готовоеstack и просмотрев NewThreadStack. В этом представлении показаны три связанные функции, как показано на рисунке 35 ввода-вывода и таймере в NewThreadStack:

   

   Рис. 35 ввода-вывода и таймера в NewThreadStack

   Это представление раскрывает следующие сведения:

   • Поток 3872 процесса TestBootStrapper.exe (3024) очищает куст реестра для 544 миллисекунда.

   • Поток 3872 процесса TestBootStrapper.exe (3024) спит в 513 миллисекундах.

   • Поток 3872 процесса TestBootStrapper.exe записывает на диск 3,5 МБ, что приводит к задержке в 178 миллисекунда.

9. Когда вы начали исследовать критический путь, вы проанализировали наиболее значительную причину ожидания в Explorer.exe и проигнорировали все части критического пути, который произошел после этой причины ожидания. Чтобы записать этот ранее игнорируемый раздел критического пути, необходимо просмотреть временную шкалу. Добавьте использование ЦП (точно) и примените временную шкалу по процессу, предустановке потока .

10. Фильтр для включения только процессов, определенных как часть критического пути. Результирующий график показан на рисунке 36 критического пути временной шкалы:

    

    Рис. 36 временная шкала критического пути

    Рис. 36 Временная шкала критического пути показывает, что Explorer.exe выполнил больше работы после остановки ожидания RunOnce.exe. Увеличьте масштаб до периода времени после ранее проанализированной цепочки ожидания и выполните другой анализ. В этом случае анализ показывает большое количество потоков, которые являются внутренними для Explorer.exe, и нет четкой трассировки через критический путь. В этом случае дальнейший анализ, скорее всего, не дает полезных сведений.

Прямое использование ЦП

Действия часто задерживаются, так как поток на критическом пути использует значительное время ЦП. Используя модель состояния потока, можно увидеть, что эта проблема характеризуется потоком на критическом пути, который тратит исключительное время в состоянии выполнения. На некоторых оборудованиях это интенсивное использование ЦП может способствовать задержкам.

Идентификация проблемы

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

Использование ЦП по процессу P задерживает затронутое действие A в течение x секунд

Где P — это выполняемый процесс, А — это действие, а x — это время в секундах.

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

Изучение прямого использования ЦП

1. Вы можете вручную определить проблему, найдите отдельные ЦП, которые потребляют 100 % использования ЦП в графе использования ЦП (выборка).

2. Увеличьте область интереса к графу и выберите предустановку "Использование по процессу и потоку ".

   По умолчанию в таблице отображаются строки в верхней части, которые имеют наибольшее совокупное использование ЦП. Эти потоки также отображаются в верхней части графа использования ЦП (выборка).

   Примечание. В системе с несколькими процессорами поток, использующий 100 % одного процессора, будет потреблять 100/(число логических процессоров). В этой системе только виртуальный поток простоя (PID 0, TID 0) может отображать больше использования процессора, чем 100/(число логических процессоров). Если процессы и потоки, которые потребляют большую часть ЦП, соответствуют любым потокам в критическом пути, прямое использование ЦП, вероятно, является фактором.

Пример проблемы с прямым использованием ЦП, сообщаемой об оценке

Использование ЦП процессом TestUM.exe (4024) задерживает затронутую активность, процесс быстрого завершения запуска TestIM.exe в течение 2,1 секунды. Этот пример показан на рисунке 37 Thread 3208:

Рис. 37 Поток 3208

Исследование

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

Метод. Проверка проблемы с прямым использованием ЦП с оценкой

Вы можете развернуть проблему с прямым использованием ЦП, чтобы отобразить критически важный путь, который влияет на прямое использование ЦП. Если развернуть узел, связанный с использованием ЦП, будут отображаться стеки, связанные с использованием ЦП и связанными модулями. Это представление показано на рис. 38 Расширенный сегмент использования ЦП:

Рис. 38 Расширенный сегмент использования ЦП

Метод. Изучение стеков прямого использования ЦП вручную

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

Изучение стеков прямого использования ЦП вручную

1. В меню "Трассировка" щелкните "Загрузить символы".

2. Увеличьте временную шкалу, чтобы отобразить только часть критического пути, затронутого проблемой ЦП.

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

4. Добавьте столбец Stack на экран и перетащите этот столбец справа от идентификатора потока (слева от панели).

5. Разверните процесс и поток, чтобы отобразить деревья стека.

   Строки в стеке сортируются в порядке убывания по %весу использования ЦП. Это ставит самые интересные стеки сверху. При развертывании стеков просмотрите столбец %Weight , чтобы убедиться, что фокус остается на строках, имеющих наибольшее использование.

6. Чтобы извлечь копию стека, выберите все строки, щелкните правой кнопкой мыши и нажмите кнопку " Копировать выделение".

Разрешение

Средства защиты можно применять как на уровне конфигурации, так и на уровне компонентов, чтобы устранить высокую загрузку ЦП.

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

• Удаление кода с большим объемом ЦП из критического пути

• Использование более эффективных алгоритмов ЦП

• Отложить или кэшировать работу

Интерференция потока

Использование ЦП потоками, которые не находятся на критическом пути (и которые могут быть не связаны с действием), могут привести к задержке потоков, которые находятся на критическом пути. Модель состояния потока показывает, что эта проблема характеризуется потоками на критическом пути, который тратит необычное время в состоянии готовности.

Идентификация проблемы

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

• Процесс P голодает. Голод вызывает задержку в затронутом действии A x мс.

• Процесс P предопределен. Прерывание приводит к задержке в затронутом действии A x мс.

Где P — это процесс, А — это действие, а x — время в мс.

Первая форма отражает вмешательство потоков на том же уровне приоритета, что и поток на критическом пути. Вторая форма отражает вмешательство потоков, которые находятся на более высоком уровне приоритета, чем поток на критическом пути.

Если эти типы проблем сообщаются для отложенного действия, вмешательство потоков может быть причиной. Вы можете использовать граф использования ЦП (точный), чтобы вручную определить проблему.

Определение проблем с помехами потока

1. Увеличьте интервал и примените к нему предустановку загрузки ЦП . Использование 100 % во всех ЦП указывает на проблему вмешательства.

2. Примените метод использования по процессу, предустановке потока и отсортируйте по первому столбцу Ready (us). (Это столбец, включающий в себяСумма агрегирования.)

3. Разверните процесс затронутых действий и просмотрите время готовности потоков на критическом пути. Это значение является максимальным временем, когда задержка может быть сокращена путем устранения любой проблемы с вмешательством потока. Значение со значительной величиной относительно расследуемой задержки указывает на то, что существует проблема с вмешательством потока.

Рис. 39 Загрузка ЦП составляет около 100 % и рис. 40 Проблема интерференции потоков представляет этот сценарий:

Рис. 39 Загрузка ЦП составляет около 100 %

Рис. 40 Проблема интерференции потоков

Исследование

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

Метод. Определение того, почему поток потратил время в состоянии готовности

Вы можете использовать граф использования ЦП (точный) для определения того, почему поток потратил время в состоянии готовности. Сначала необходимо определить, ограничен ли поток определенными процессорами. Хотя вы не можете получить эти сведения напрямую, вы можете изучить журнал использования ЦП потока в периоды высокой загрузки ЦП. Это период, когда потоки часто переключаются между процессорами.

Определение ограничений процессора потока

1. Увеличьте масштаб затронутой области.

2. Добавьте граф использования ЦП (точный) и примените предварительное определение использования по процессу, потоку.

3. Используйте диалоговое окно "Дополнительно ", чтобы добавить столбец ЦП с режимом агрегирования "Уникальное число" справа от NewThreadId.

4. Отфильтруйте граф, чтобы отобразить только интересующие вас потоки.

   Значение в столбце ЦП отражает количество процессоров, на которых поток выполнялся в течение текущего интервала времени. В течение 100 % использования ЦП это число приблизит количество процессоров, на которых разрешено запускать этот поток. Если значение меньше числа доступных процессоров, поток, вероятно, ограничен определенными ЦП.

   Рис. 41 Ограниченные потоки приведен пример этого графа:

   

   Рис. 41 Ограниченные потоки

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

Определение того, что предвиделось или голодал поток

1. Создайте граф, показывающий, когда поток был в состоянии "Готово" и применяет использование по процессу, предустановке потока .

2. Откройте редактор представления, нажмите кнопку "Дополнительно" и перейдите на вкладку "Конфигурация графа".

3. Задайте для параметра "Время начала" значение ReadyTime (s) и задайте значение "Время готовности" (us)), как показано на рис. 42 Столбцы времени готовности. Щелкните OK.

   

   Рис. 42 Столбцы времени готовности

4. В редакторе представлений замените столбец "Использование ЦП" (%) столбцом Ready (us) [Sum].

5. Выберите интересующий поток, чтобы создать граф, похожий на рис. 43 Готовый график времени:

   

   Рис. 43 График времени готовности

6. В этом случае поток провел значительное время в состоянии готовности. Чтобы определить типичный приоритет, добавьте среднее агрегирование в столбец NewInPri.

   В этом случае средний приоритет потока составляет ровно 8. Это число указывает, что это, вероятно, фоновый поток, который никогда не получает повышение приоритета.

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

   В этом случае поток должен иметь сходство только для ЦП 1.

8. Добавьте еще один граф использования ЦП (точный) и примените предустановку загрузки ЦП . Выберите соответствующие ЦП.

9. Откройте расширенное представление и добавьте фильтр для приоритета, который вы нашли ранее, чтобы отфильтровать этот поток. Этот сценарий показан на рисунке 44 Фильтра потоков:

   

   Рис. 44 Фильтр потоков

   На рисунке 45 загрузка ЦП, время готовности и другое действие потока в верхней диаграмме показана загрузка ЦП потока 3548. Средний граф показывает время, когда поток был готов, а нижний граф показывает действие на ЦП, на котором поток был разрешен выполнять (в данном случае ЦП1).

   

   Рис. 45 Использование ЦП, время готовности и другое действие потока

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

11. В графе использования ЦП добавьте NewInPri слева от панели и проверьте результаты.

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

    Рис. 46 Использование по приоритету, когда целевой поток был готов, показывает, что 730 мс времени потока были упрежены, и 300 мс времени потока были голодать. (Этот рисунок увеличен до интервала в 1192 мс.)

    

    Рис. 46. Использование по приоритету при готовности целевого потока

12. Чтобы определить, какие потоки отвечают за упрежение и нехватку этого потока, добавьте столбец NewProcess справа от столбца NewInPri и просмотрите уровни приоритета, на которых выполнялись процессы. В этом случае прерывание и голодание были в основном вызваны другим потоком в том же процессе и TestResidentApp.exe. Можно предположить, что эти процессы получают периодические повышения приоритета выше базового приоритета.

Разрешение

Вы можете устранить проблемы с прерыванием или нехваткой, изменив конфигурацию или компоненты. Рассмотрим следующие средства защиты:

• Удалите проблемные процессы из системы.

• Настройте базовый приоритет проблемных процессов...

• Измените время выполнения проблемных процессов; Например, задержка времени начала выполнения при перезагрузке компьютера.

• Если компоненты проблемы могут быть изменены, измените их так, чтобы они были менее интенсивными или выполнялись в более низком приоритете.

Вмешательство DPC/ISR

Если чрезмерное время процессора потребляется при выполнении ЦП и isR, возможно, недостаточно свободного времени ЦП для запуска потоков. Такая ситуация может привести к аналогичным задержкам в интерференции потока. Когда потоки должны выполнять операции с обычной высокой частотой, например при воспроизведении видео или анимации, вмешательство DPCs и ISR могут вызвать операционные проблемы.

Идентификация проблемы

Многие оценки используют эвристики для выявления проблем, связанных с DPC/ISR. Действие DPC/ISR определяется как подозрительное, когда оно сообщается как проблема в следующей форме:

DPC D превышает пороговое значение в миллисекундах x во время P. N экземпляров этого DPC выполняется для объединенного количества миллисекунда.

Где D — DPC, m — это число миллисекунд, задающее пороговое значение, x — это число превышения порогового значения DPC, P — это текущее число экземпляров, число запущенных DPC, а в миллисекундах — общее время, которое DPC выполнялся через пороговое значение.

Например, по оценке сообщается следующая проблема:

DPC sdbus.sys! SdbusWorkerDpc превышает цель в 3,0 миллисекундах 153 раза во время существования ядра мультимедиа. 153 экземпляров этого DPC выполняются в общей сложности в 864 миллисекундах

Если эта проблема отображается для действия, которое отображает события проблем или задержки, действие DPC/ISR может быть причиной.

Определение помех DPC/ISR вручную

1. Чтобы вручную определить помехи DPC/ISR, откройте трассировку в WPA и определите интересующие проблемы события. Это универсальные события, относящиеся к оценке, такие как Microsoft-Windows-Dwm-Core:SCHEDULE_GLITCH или Microsoft-Windows-MediaEngine:DroppedFrame.

2. Рядом с графом событий добавьте длительность DPC/ISR по графу ЦП . Если пики в длительности DPC/ISR по графику ЦП соответствуют событиям проблемы, DPC/ISR может быть фактором, вызывающим проблемы.

3. Для получения дополнительных данных увеличьте период времени, который происходит 100 мс перед отображением нескольких событий проблем. Если значительное действие DPC/ISR отображается на одном или нескольких процессорах в регионе 100 мс до возникновения проблемных событий, можно заключить, что события проблемы были вызваны действием DPC/IRS.

4. Чтобы определить, вызывает ли помехи DPC/ISR, увеличьте масштаб до региона, отображающего выполняющийся поток. Запишите ЦП или ЦП, на которых выполняется этот поток.

5. На графе DPC/ISR примените длительность DPC/ISR по предустановке ЦП и просмотрите действие DPC/ISR на соответствующих ЦП в этом диапазоне времени.

Рис. 47 Событий проблем и действия DPC/ISR показывают, что поток 864 из iexplore.exe относится к затронутой активности. Поток 864 находится в состоянии "Выполнение" на ЦП2 для 10,65% диапазона времени в представлении. Однако на графике DPC/ISR показано, что ЦП2 был занят выполнением DPC/ISR в течение 10% этого времени.

Обратите внимание, что большинство DPC/ISR не имеют такого большого влияния, как показано в этом примере.

Рис. 47 событий проблемы и действия DPC/ISR

На рисунке 48 DPC/ISR, не связанном с событиями проблем, DPC/ISR отображаются как не связанные с проблемами производительности:

Рис. 48 DPC/ISR, не связанные с событиями проблем

На рисунке 49 Задержка, вызванная помехами DPC/ISR, отображаются DPC/ISR, чтобы вызвать проблемы с производительностью:

Рис. 49 Задержка, вызванная помехами DPC/ISR

Исследование

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

Метод. Проверка проблемы DPC/ISR с оценкой

В сообщениях об ошибках DPC/ISR можно развернуть проблему, которая отображает основные процессы, предопределенные DPC или ISR. Разверните стек, чтобы просмотреть действие DPC для процесса, который наиболее связан с затронутым действием, как показано в примере, разверните стек, чтобы понять, что делает DPC. На рисунке 50 развернутый стек DPC показан развернутый стек:

Рис. 50 Развернутый стек DPC

Метод. Поиск наиболее длительности DPCs/ISR и проверка стеков

Если оценка не сообщает о проблеме DPC/ISR, вы можете использовать графы DPC/ISR и использование ЦП (примеры) для получения сведений о стеке для наиболее важных ЦП. Рекомендуется найти интересующий объект DPC/ISR, запишите его модуль и функцию, а затем найдите примеры в графе использования ЦП (примеры), чтобы получить полные сведения о стеке.

Поиск наиболее длительности DPCs/ISR и проверка стеков

1. Увеличьте интервал интереса.

2. На графе DPC/ISR выберите предустановленную длительность DPC/ISR по модулю.

   Если символы загружаются, события DPC/ISR сортируются по общей длительности и затем разбиваются по модулю и функции. Верхние строки в списке содержат события DPC/ISR, которые, вероятно, вызвали проблемы с событием. Запишите имена модулей и функций.

3. На графике использования ЦП (выборка) выберите предустановку "Использование по процессу ". По умолчанию этот предустановка скрывает действие DPC/ISR.

4. Откройте редактор представления и нажмите кнопку "Дополнительно".

5. На вкладке "Фильтр" измените строки скрытия, соответствующие параметру фильтра, чтобы сохранить строки, соответствующие фильтру. Это позволит отображать действия DPC/ISR.

6. Удалите столбец Process и добавьте столбец Stack для просмотра DPCs/ISR, отсортированных по стеку.

7. Снимите текущий выбор строки.

8. Щелкните правой кнопкой мыши ячейку в столбце Stack и выберите команду "Найти в этом столбце".

9. Введите модуль и функцию, отмеченную на шаге 2 этой процедуры.

10. Установите флажок "Добавить к текущему выбору" и нажмите кнопку "Найти все" , чтобы выбрать все экземпляры функции.

11. После выбора всех строк щелкните правой кнопкой мыши и щелкните "Бабочка" или "Просмотреть вызываемые".

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

Это представление отображается на рисунке 51 Вызовы DPC, отсортированные по приблизительной длительности:

Рис. 51 Вызовы DPC, отсортированные по приблизительной длительности

Метод. Проверка длительных DPCs/ISR

Общая длительность ЦП/ISR важна, но длительные отдельные ЦП/ISR, скорее всего, вызывают задержки. На графе DPC/ISR столбец "Инклюзивная длительность( мс) сортируется по убыванию, отображает максимальную длительность отдельных DPC/ISR. Предустановка long DPCs/ISR, доступная в некоторых профилях оценки, позволяет фильтровать это представление для отображения только ЦП/ISR с инклюзивной длительностью, превышающей 1 мс.

Примечание. Если эта предустановка недоступна, можно открыть раздел "Редактор представлений", "Дополнительно ", чтобы добавить фильтр.

Разрешение

Действие DPC/ISR часто отражает проблему оборудования или программного обеспечения, которая должна быть исправлена на уровне оборудования или компонента. На уровне конфигурации можно заменить оборудование или обновить связанный драйвер до фиксированной версии. На уровне компонентов оборудование и драйверы должны следовать рекомендациям для ЦП/ISR из MSDN и по возможности использовать потоковые ЦП. Потоковые ЦП не выполняются на уровне отправки в клиентских выпусках Windows. Дополнительные сведения о рекомендациях по работе с ЦП/ISR см. в рекомендациях по поведению ISR и DPC и внедрению в потоковые ЦП.

См. также

Общие сведения о потоковом ЦП

Загрузка символов

Управление питанием и ACPI — поддержка архитектуры и драйверов

PPM в Windows Vista и Windows Server 2008

Планирование приоритетов

Планирование, контекст потока и IRQL

Внутренние компоненты Windows, Шестой выпуск

Windows Performance Analyzer

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