Одна из самых распространенных проблем, с которой потребители обращаются в группу поддержки Microsoft, — слишком высокие показатели использования центрального процессора. Часто найти решение бывает трудно, так как необходимо сначала определить, какой процесс или операция потребляет много ресурсов центрального процессора, а затем выбрать оптимальный метод сбора данных о действиях процесса в период проявления проблемы, чтобы исследовать основную причину. На этот случай компания Microsoft предоставляет целый ряд инструментов, которые помогут решить проблему центрального процессора. В данной статье приведен краткий обзор этих средств и описана новая бесплатная утилита под названием ProcDump, с помощью которой можно сэкономить много времени, когда в следующий раз придется искать причины перегрузки центрального процессора.
Инструменты диагностики
До сих пор для диагностики проблем высокого показателя использования центрального процессора в компьютерах Windows применялись в основном следующие инструменты.
Adplus.vbs. Инструмент на VBscript, поставляется в составе пакета Debugging Tools for Windows (www.microsoft.com/whdc/devtools/debugging/default.mspx). Это отличное средство для сбора данных о процессе в периоды высокой нагрузки на процессор. Один из недостатков Adplus заключается в том, администратор обычно вынужден находиться у консоли и физически вводить команду Adplus для формирования дампа процесса, когда показатель использования центрального процессора резко возрастает.
Xperf. Это отличный инструмент для сбора данных об активности процесса во время резкого роста коэффициента использования центрального процессора. Администратору не обязательно находиться у консоли для мониторинга нагрузок центрального процессора. Xperf можно загрузить по адресу msdn.microsoft.com/en-us/performance/default.aspx. Утилита Xperf не полностью совместима с Windows Server 2003, но наш опыт сбора данных об операциях со стеком в Windows 2003 (важные сведения для анализа проблем высоких показателей использования центрального процессора) был очень успешным. Нужно лишь загрузить программное исправление по адресу support.microsoft.com/kb/938486 или установить ядро с более новой версией.
При использовании XPERF необходимо учитывать, что инструмент собирает данные обо всех процессах и активности в системе и лишь впоследствии позволяет сузить зону поиска. Поэтому нельзя сформулировать условие: «Пройти стек для XYZ.EXE», приходится собирать данные обо всей системе. Сбор и запись всех данных об активности в поисках проблемы, которая возникает лишь один раз в сутки, могут оказаться нецелесообразными, в зависимости от типичной рабочей нагрузки контролируемых компьютеров. Дополнительные сведения об Xperf приведены в статье «Изучаем Xperf», опубликованной в предыдущем номере журнала.
Process Explorer (procexp.exe). Настоятельно рекомендуется использовать программу Process Explorer, которую можно загрузить по адресу technet.microsoft.com/en-us/sysinternals/bb896653.aspx, чтобы, по крайней мере, взглянуть на поток, дающий всплеск нагрузки на центральный процессор, и определить участвующие компоненты. Их можно обновить, прежде чем обращаться в службу технической поддержки. Но для углубленного изучения проблемы требуется инструмент, который формирует дамп процесса во время пика использования центрального процессора; Process Explorer для этого непригоден (дополнительные сведения об Adplus и Process Explorer можно найти в статье «Когда процессы выходят из-под контроля» по адресу http://www.osp.ru/win2000/2009/01/5889733/). Но такие возможности есть у ProcDump.
Введение в ProcDump
ProcDump (procdump.exe) — новый инструмент Windows Sysinternals, созданный Марком Русиновичем, который можно загрузить по адресу technet.microsoft.com/en-us/sysinternals/dd996900.aspx. Программа Procdump.exe была разработана после того, как один из инженеров моей группы попросил Марка дополнить функциональность Process Explorer, чтобы записать файл дампа процесса для анализа проблем высокого показателя использования центрального процессора. После некоторых раздумий было решено, что лучший вариант — подготовить новую программу, и появился ProcDump.
С помощью ProcDump можно указать, сколько ресурсов центрального процессора должен занимать процесс и какое время должно пройти, прежде чем ProcDump создаст дамп процесса. Значит, администратору не обязательно присутствовать у консоли, чтобы выдать команду, когда процесс в очередной раз повысит нагрузку на центральный процессор. Необходимо определить порог потребления ресурсов центрального процессора, прежде чем ProcDump сформирует дамп процесса.
Например, замечено, что wmiprvse.exe (процесс WMI Provider Host) в произвольные моменты времени занимает до 90% ресурсов центрального процессора, и нужно получить несколько дампов для анализа. Следующая команда записывает дамп процесса диспетчера очереди печати три раза, когда потребление ресурсов центрального процессора программой wmiprvse.exe достигает или превышает 90% в течение трех секунд, и сохраняет дамп в заранее подготовленном каталоге c:procdumps:
c:procdump.exe -c 80-s 3-n
3 wmiprvse.exe c:procdumps
Параметр -c задает порог нагрузки центрального процессора. Параметр -s указывает, в течение какого времени служба должна занимать ресурсы центрального процессора на пороговом уровне, прежде чем начнется формирование дампа. Параметр -n указывает, сколько дампов нужно создать, а wmiprvse.exe — имя процесса, который предстоит отслеживать.
Поэтому в предшествующей команде дамп для службы WMI Provider Host будет записываться каждый раз, когда процесс занимает более 80% ресурсов центрального процессора в течение трех и более секунд. Файлы дампов будут храниться в каталоге c:procdumps. Имя файлам дампов назначается в формате ИМЯПРОЦЕССА_ДАТА_ВРЕМЯ.dmp; благодаря временной метке легко идентифицировать файлы, записанные в течение нескольких дней. Другая особенность ProcDump заключается в том, что поток, занимающий больше всего ресурсов центрального процессора, записывается в файл дампа, поэтому, открывая дамп, пользователь видит сообщение о потоке, занимающем центральный процессор, как показано на экране 1.
Больше не приходится гадать, какой поток выполняет работу. В окне экрана 1 можно ввести в отладчике команду ~ (тильда), чтобы выяснить, какой номер потока соответствует числу 0 x1194. На экране 2 показана командная строка и ее результат. Как видно, поток 2 (с числом 1194 в строке) является потоком, соответствующим 0x1194.
Я привел этот пример, чтобы продемонстрировать инструмент, но теперь можно переключить внимание на поток 2, чтобы выяснить, что происходило в то время, когда были заняты ресурсы центрального процессора. В командном окне выполните следующую команду, чтобы изменить контекст потока 2:
0:000> ~2 s
Результат команды на экране 3 показывает, что процесс wmiprvse.exe во время проведения теста перебирал различные каталоги (EnumDirsNT). Это вполне объяснимо, так как выданный мною запрос WMI требует перечисления всех каталогов в системе.
ProcDump также создаст процесс, если зависает любое из окон процесса (параметр -h); как всегда при использовании ProcDump, для запуска задачи не обязательно находиться у консоли.
Запуск процесса в отладчике
Особенно полезный параметр ProcDump (-x) обеспечивает запуск процесса непосредственно в отладчике. Параметр -x взаимодействует с разделом реестра Image File Execution Options. На экране 4 приведен пример команды, в которой параметр -x указан с процессом lsass.exe, и формируются три дампа lsass.exe, когда процесс занимает 90% ресурсов центрального процессора.
При следующем запуске lsass.exe утилита ProcDump отслеживает процесс с заданными параметрами. Это чрезвычайно удобный подход, так как существуют процессы, которые могут захватить ресурсы центрального процессора немедленно после запуска и приостановить систему до тех пор, пока центральный процессор не разгрузится, но к тому времени записывать в дамп будет нечего, так как перегрузка центрального процессора произошла. Благодаря параметру -x можно собрать данные об этих перегрузках.
Таким образом, ProcDump может быть оптимальным инструментом для диагностики большинства проблем высокой загрузки центрального процессора. Утилита ProcDump спроектирована в результате инициативы сотрудников группы Global Escalation Services компании Microsoft. Особая благодарность — старшему инженеру Мин Ченю, который первым обратился к Марку; ведущему инженеру Джеффу Дейли — за руководство и ценные указания; и, конечно, огромная благодарность Марку Русиновичу, ведущему техническому специалисту Microsoft, за то, что он прислушивается к нашим пожеланиям и быстро вносит изменения.
Майкл Моралес (morales@microsoft.com) — старший инженер службы поддержки Microsoft Global Escalation Services. Специализируется на проблемах отладки и производительности Windows