Что грузит процессор

Данная короткая заметка будет посвящена теме обнаружения источника внезапной нагрузки на процессор. Нагрузка на процессор, ну и что? В процессе работы с операционной системой Windows внезапные тормоза являются штатной реакцией на загрузку нами "прожорливых" приложений, например открытие большого количества "тяжелых" (использующих графические объекты на странице) вкладок в браузере Internet Explorer. Тут все прогнозируемо, ибо причиной подобных проблем является работа требовательного к ресурсам приложения, которое в зависимости от специфики выполняемой задачи способно сильно нагружать процессор. Совершенно другое дело, когда нагрузка на процессор возникает сама по себе, без видимых на то причин.

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

• Высокая нагрузка на процессор, внезапно появляющаяся и (не)исчезающая через некоторый промежуток времени;
• Постоянная нагрузка на процессор, не меняющая своих симптомов на протяжении всего цикла функционирования операционной системы;

В описанных ситуациях не исключены варианты, когда процессор загружен на 100 процентов, либо загрузка может быть не полной. Так же можно выделить постоянную, либо интервальной загрузку. Как в описанных ситуациях определить что грузит процессор? Что бы ответить на этот вопрос, потребуется обнаружить процесс, функционирующий в операционной системе и являющийся источником аномальной нагрузки. И в этом нам поможем специализированное программное обеспечение.

Установка WPT

Сперва нам потребуется произвести установку инструментария под названием Windows Performance Toolkit (WPT), который входит в состав Windows SDK. Процесс установки подробно описан в статье Установка Debugging Tools for Windows, по ней можно с легкостью установить и Windows Performance Toolkit, просто в процессе установки не забудьте отметить пункт "Windows Performance Toolkit". Помните, что лучше было бы установить дистрибутив, соответствующий разрядности Вашей платформы. По окончании процесса установки возможные рабочие каталоги инструментария:

• C:\Program Files\Microsoft Windows Performance Toolkit;
• C:\Program Files (x86)\Windows Kits\8.x\;

..хотя пути могут в будущих дистрибутивах и измениться.

Создание нагрузки

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

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

Для создания нагрузки мы будем использовать утилиту под названием CPUSTRES от Sysinternals. Утилита старая, быть может уже в среде Windows 7 не совсем актуальная, однако это первая вещь, которая подвернулась мне под руку. Сразу после старта утилита запускает на выполнение первичный поток и выводит графический интерфейс пользователя, содержащий настройки:

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

Мониторинг

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

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

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

xperf -on latency -stackwalk profile -buffersize 2048 -MaxFile 1024 -FileMode Circular && timeout -1 && xperf -d c:\cpu.etl

Что происходит после выполнения приведенной серии команд?

• При помощи контроллера xperf включается сессия трассировки ядра с опцией latency (задержка). Latency это группа, которая включает некоторое количество предопределенных провайдеров ядра, в числе которых есть и профилирование, фиксирующее активность процессора каждую миллисекунду. Опция Stackwalk Profile предписывает записывать стек вызова каждый раз при возникновении события профилирования процессора.
• Команда timeout -1 ожидает нажатия пользователем любой клавиши;
• После нажатия клавиши, командой xperf -d c:\cpu.etl контроллер инициирует завершение сессии трассировки событий и сохраняет результаты в файл c:\cpu.etl.

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

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

Ошибки

При первом запуске утилиты xperf возможно появление следующих оповещений и ошибок:

Это предупреждение никак не влияющее на текущую сессию трассировки и может быть проигнорировано. Оно сообщает нам о том, что система не сконфигурирована должным образом для трассировки стека 64-битных процессов. Текущая настройка разрешает выгрузку страниц, содержащих исполняемый код ядра/драйверов из оперативной памяти в файл подкачки. Намекает, что неплохо было бы, в будущем, включить запрет выгрузки страниц ядра из оперативной памяти. Просто присвойте параметру значение "1" и перезагрузитесь.

Довольно странная ошибка, в локализованной версии звучащая как "Не могу создать файл, потому что файл уже используется". Говорит о том, что в данный момент уже запущена трассировка через какое-то из системных/сторонних средств. Для решения проблемы требуется отключить трассировку, универсальным средством лечения так же является перезагрузка :)

Анализ результатов

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

• Для старых версий WPT это xperfview.exe;
• Для новых версий WPT это wpa.exe;

Откроется основное окно программы Windows Performance Analyzer:

Вид окна от версии к версии может меняться. Нам принципиально найти график под названием CPU Usage (Sampled) или CPU Sampling by Process. Например, для старых версий, в меню Graphs ставим чек-бокс напротив опции CPU Sampling by Process. После чего в основном окне у нас появится соответствующий график.

CPU Sampling - Замеры затрачиваемого на процессы процессорного времени на протяжении всего цикла трассировки.

На этом графике мы можем наблюдать характерные всплески нагрузки, вызванные активностью утилиты CPUStres. Ось ординат данного графика отображает процент использования ЦП. На любом месте графика CPU Sampling by Process жмем правую кнопку мыши и из раскрывшегося контекстного меню выбираем пункт Summary Table. Откроется новое окно:

Открывшееся окно CPU Sampling Summary Table может выглядеть слегка иначе, поскольку в умолчальном своем состоянии, обычно, не отображает колонку Stack (Стэк). В этом случае для проведения окна к описанному виду, вызываем пункт меню Columns (Столбцы) и отмечаем чек-бокс Stack.

Что же мы наблюдаем в суммарной таблице? Столбец Count (Счет) отображает количество замеров, которые были произведены для каждого процесса. А столбец Weight (Вес), в свою очередь, определяет количество времени, затраченного на эти замеры (в миллисекундах). Более внимательные читатели могли заметить, что значения столбцов практически идентичны, с небольшим расхождением. Это объясняется частотой интервала замеров, равной 1 КГц (KHz). А небольшие расхождения значений Weight и Count объясняется тем, что интервалы замеров не идеально выверены. Процессы отсортированы по уменьшению значения Weight, что, в общем то, является удобным критерием сортировки, поскольку размещает процессы по убыванию количества затраченного на них времени.

Обе этих колонки (Weight/Count) отражают степень использования процессора, что, в общем то, в контексте данной задачи для нас самое важное.

Какая тут может применяться методика поиска виновника интенсивного использования процессора? Поскольку самые нагружающие процессор приложения находятся вверху и отсортированы вниз по мере убывания нагрузки, то сверху мы и будем анализировать список процессов. Для каждого процесса в столбце Stack разворачиваем все имеющиеся сгруппированные стеки вызовов значком [+], таким образом у нас должно получиться что-то вроде иерархической структуры. В развернутых стеках вызовов конкретного процесса просматриваем все расположенные там модули. Нас интересуют только те модули, у которых колонка Weight имеет большие значения и после которого в следующей строке идет резкое падение затрачиваемого процессорного времени.

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

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

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

Выводы

Таким образом мы ответили на вопрос о том, что грузит процессор. Но для чего нужны все эти инструменты из комплекта Windows Performance Tools, ведь мы могли бы просто вызвать Диспетчер задач в момент нештатной нагрузки и отследить источник проблемы использования центрального процессора (ЦП). Да, подобный подход действительно актуален, но только для приложений! А описанный в данной статье метод с использованием утилит комплекта WPT позволяет находить массу дополнительной информации по сбою:

• источник проблемы среди модулей режима ядра (процессов/драйверов), выполняющихся в контексте процесса System;
• источник проблемы среди процессов сервисов (служб), группирующихся в рамках единых процессов svchost.exe;
• видеть стеки вызовов модулей, что намного глубже позволяет погрузиться в изучение сбоя.