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

Windows 7: выявление "тяжелых" процессов

Чтобы узнать конкретный уровень загрузки процессора, используйте встроенный в операционную систему инструмент - диспетчер задач. Чтобы открыть его, достаточно нажать на сочетание клавиш Ctl+Shift+Esc. Кликните по кнопке "Отобразить процессы всех пользователей". Во всплывающем окне выберите «ДА». Теперь диспетчер задач запущен с правами администратора.

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

Высокая Windows 7: что делать?

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

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

Process Explorer

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

Как снизить нагрузку на ЦП Windows 7 при помощи Process Explorer? В окне программы отсортируйте список процессов по нагрузке на CPU. Изучите таблицу на предмет подозрительных приложений. Если такие есть, щелкните по имени программы правой кнопкой мыши и выберите Kill Process.

Системные прерывания

Откройте и обратите внимание на надпись «interrupts». Если напротив нее в столбце CPU значение превышает 1-2%, значит, процессор занят обработкой системных прерываний. В этом случае выявить источник проблемы очень трудно. Следует попробовать проверить компьютер на вирусы, обновить драйвера, проверить на ошибки или установить новый жесткий диск. Не лишним будет отключить периферийное оборудование.

Драйвера

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

1. Перезагрузите компьютер.
2. Перед включением ОС несколько раз нажмите на кнопку F8 на клавиатуре.
3. В открывшемся меню выберите пункт «Безопасный режим».
4. После загрузки операционной системы запустите приложение Process Explorer и какое-то время понаблюдайте за строкой interrupts.

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

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

Перегрев

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

Периферийное оборудование

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

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

Компьютерные игры

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

Как снизить нагрузку на ЦП Windows 7, если апгрейд невозможен? Попробуйте перед запуском игры закрыть все лишние приложения. Отключите компьютер от сети, чтобы он не начал неожиданно скачивать обновления для своего ПО. Закройте антивирусные программы, ведь этот тип ПО расходует очень много ресурсов компьютера. Антивирус следит абсолютно за всей активностью ПК, что негативно сказывается на его производительности.

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

• Перевод

Та метрика, которую мы называем «загрузкой процессора» на самом деле многими людьми понимается не совсем верно. Что же такое «загрузка процессора»? Это то, насколько занят наш процессор? Нет, это не так. Да-да, я говорю о той самой классической загрузке CPU, которую показывают все утилиты анализа производительности - от диспетчера задач Windows до команды top в Linux.

Вот что может означать «процессор загружен сейчас на 90%»? Возможно, вы думаете, что это выглядит как-то так:

А на самом деле это выглядит вот так:

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

Что это означает для вас? Понимание того, какое количество времени процессор действительно выполняет некоторые операции, а какое - лишь ожидает данные, иногда даёт возможность изменить ваш код, уменьшив обмен данных с оперативной памятью. Это особенно актуально в нынешних реалиях облачных платформ, где политики автоматического масштабирования иногда напрямую завязаны на загрузку CPU, а значит каждый лишний такт «холостой» работы стоит нам вполне реальных денег.

Что же такое загрузка процессора на самом деле?

Та метрика, которую мы называем «загрузкой процессора» на самом деле означает нечто вроде «время не-простоя»: то есть это то количество времени, которое процессор провёл во всех потоках кроме специального «Idle»-потока. Ядро вашей операционной системы (какой бы она ни была) измеряет это количество времени при переключениях контекста между потоками исполнения. Если произошло переключение потока выполнения команд на не-idle поток, который проработал 100 милисекунд, то ядро операционки считает это время, как время, потраченное CPU на выполнение реальной работы в данном потоке.

Эта метрика впервые появилась в таком виде одновременно с появлением операционных систем с разделением времени. Руководство программиста для компьютера в лунном модуле корабля «Апполон» (передовая на тот момент система с разделением времени) называла свой idle-поток специальным именем «DUMMY JOB» и инженеры сравнивали количество команд, выполняемых этим потоком с количеством команд, выполняемых рабочими потоками - это давало им понимание загрузки процессора.

Так что в этом подходе плохого?

Сегодня процессоры стали значительно быстрее, чем оперативная память, а ожидание данных стало занимать львиную долю того времени, которое мы привыкли называть «временем работы CPU». Когда вы видите высокий процент использования CPU в выводе команды top, то можете решить, что узким местом является процессор (железка на материнской плате под радиатором и кулером), хотя на самом деле это будет совсем другое устройство - банки оперативной памяти.

Ситуация даже ухудшается со временем. Долгое время производителям процессоров удавалось наращивать скорость их ядер быстрее, чем производители памяти увеличивали скорость доступа к ней и уменьшали задержки. Где-то в 2005-ом году на рынке появились процессоры с частотой 3 Гц и производители сконцентрировались на увеличении количества ядер, гипертрейдинге, много-сокетных конфигурациях - и всё это поставило ещё большие требования по скорости обмена данных! Производители процессоров попробовали как-то решить проблему увеличением размера процессорных кэшей, более быстрыми шинами и т.д. Это, конечно, немного помогло, но не переломило ситуацию кардинально. Мы уже ждём память большую часть времени «загрузки процессора» и ситуация лишь ухудшается.

Как же понять, чем на самом деле занят процессор

Используя аппаратные счетчики производительности. В Linux они могут быть прочитаны с помощью perf и других аналогичных инструментов. Вот, например, замер производительности всей системы в течении 10 секунд:

# perf stat -a -- sleep 10 Performance counter stats for "system wide": 641398.723351 task-clock (msec) # 64.116 CPUs utilized (100.00%) 379,651 context-switches # 0.592 K/sec (100.00%) 51,546 cpu-migrations # 0.080 K/sec (100.00%) 13,423,039 page-faults # 0.021 M/sec 1,433,972,173,374 cycles # 2.236 GHz (75.02%) stalled-cycles-frontend stalled-cycles-backend 1,118,336,816,068 instructions # 0.78 insns per cycle (75.01%) 249,644,142,804 branches # 389.218 M/sec (75.01%) 7,791,449,769 branch-misses # 3.12% of all branches (75.01%) 10.003794539 seconds time elapsed
Ключевая метрика здесь это "количество инструкций за такт " (insns per cycle: IPC), которое показывает, сколько инструкций в среднем выполнил процессор на каждый свой такт. Упрощённо: чем больше это число, тем лучше. В примере выше это число равно 0.78, что, на первый взгляд кажется не таким уж плохим результатом (78% времени выполнялась полезная работа?). Но нет, на этом процессоре максимально возможным значением IPC могло бы быть 4.0 (это связано со способом получения и выполнения инструкций современными процессорами). То есть наше значение IPC (равное 0.78) составляет всего 19.5% от максимально возможной скорости выполнения инструкций. А в процессорах Intel начиная со Skylake максимальное значение IPC уже равно 5.0.

В облаках

Когда вы работаете в виртуальном окружении, то можете и не иметь доступа к реальным счетчикам производительности (это зависит от используемого гипервизора и его настроек). Вот статья о том, как это работает в Amazon EC2 .

Интерпретация данных и реагирование

Если у вас IPC < 1.0 , то я вас поздравляю, ваше приложение простаивает в ожидании данных от оперативной памяти. Вашей стратегией оптимизации производительности в данном случае будет не уменьшение количества инструкций в коде, а уменьшение количества обращений к оперативной памяти, более активное использование кэшей, особенно на NUMA-системах. С аппаратной точки зрения (если вы можете на это влиять) будет разумным выбрать процессоры с большими размерами кэшей, более быструю память и шину.

Если у вас IPC > 1.0 , то ваше приложение страдает не столько от ожидания данных, сколько от чрезмерного количества выполняемых инструкций. Ищите более эффективные алгоритмы, не делайте ненужной работы, кэшируйте результаты повторяемых операций. Применение инструментов построения и анализа Flame Graphs может быть отличным способом разобраться в ситуации. С аппаратной точки зрения вы можете использовать более быстрые процессоры и увеличить количество ядер.

Как вы видите, я провёл черту по значению IPC равному 1.0. Откуда я взял это число? Я рассчитал его для своей платформы, а вы, если не доверяете моей оценке, можете рассчитать его для своей. Для этого напишите два приложения: одно должно загружать процессор на 100% потоком выполнения инструкций (без активного обращения к большим блокам оперативной памяти), а второе должно наоборот активно манипулировать данным в ОЗУ, избегая тяжелых вычислений. Замерьте IPC для каждого из них и возьмите среднее. Это и будет примерная переломная точка для вашей архитектуры.

Что инструменты мониторинга производительности на самом деле должны показывать

Я считаю, что каждый инструмент мониторинга производительности должен показывать значение IPC рядом с загрузкой процессора. Это сделано, например, в инструменте tiptop под Linux:

Tiptop - Tasks: 96 total, 3 displayed screen 0: default PID [ %CPU] %SYS P Mcycle Minstr IPC %MISS %BMIS %BUS COMMAND 3897 35.3 28.5 4 274.06 178.23 0.65 0.06 0.00 0.0 java 1319+ 5.5 2.6 6 87.32 125.55 1.44 0.34 0.26 0.0 nm-applet 900 0.9 0.0 6 25.91 55.55 2.14 0.12 0.21 0.0 dbus-daemo

Другие причины неверной трактовки термина «загрузка процессора»

Процессор может выполнять свою работу медленнее не только из-за потерь времени на ожидание данных из ОЗУ. Другими факторами могут быть:

• Перепады температуры процессора
• Вариирование частоты процессора технологией Turboboost
• Вариирование частоты процессора ядром ОС
• Проблема усреднённых расчётов: 80% средней загрузки на периоде измерений в минуту могут не быть катастрофой, но могут и прятать в себе скачки до 100%
• Спин-локи: процессор загружен выполнением инструкций и имеет высокий IPC, но на самом деле приложение стоит в спин-локах и не выполняет реальной работы

Выводы

Загрузка процессора стала сегодня существенно недопонимаемой метрикой: она включает в себя время ожидания данных от ОЗУ, что может занимать даже больше времени, чем выполнение реальных команд. Вы можете определить реальную загрузку процессора с помощью дополнительных метрик, таких, как количество инструкций на такт (IPC). Значения меньшие, чем 1.0 говорят о том, что вы упираетесь в скорость обмена данными с памятью, а большие - свидетельствуют о большой загруженности процессора потоком инструкций. Инструменты замера производительности должны быть улучшены для отображения IPC (или чего-то аналогичного) непосредственно рядом с загрузкой процессора, что даст пользователю полное понимание ситуации. Имея все эти данные, разработчики могут предпринять некоторые меры по оптимизации своего кода именно в тех аспектах, где это принесёт наибольшую пользу.

Данная короткая заметка будет посвящена теме обнаружения источника внезапной нагрузки на процессор. Нагрузка на процессор, ну и что? В процессе работы с операционной системой Windows внезапные тормоза являются штатной реакцией на загрузку нами "прожорливых" приложений, например открытие 100 вкладок в браузере Google Chrome. Тут все прогнозируемо, ибо причиной подобных проблем является работа требовательного к ресурсам приложения, которое в зависимости от специфики выполняемой задачи способно сильно нагружать процессор. Совершенно другое дело, когда нагрузка на процессор возникает сама по себе, без видимых на то причин. К примеру, в простаивающей, либо практически ничем не загруженной системе, выполняющей штатную работу, внезапно возникают подтормаживания. Подобную нагрузку можно классифицировать следующим образом:

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

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

Установка WPT

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

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

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

Установку на каждую новую проблемную станцию можно не производить. Достаточно лишь скопировать каталог Microsoft Windows Performance Toolkit на флешку или непосредственно на изучаемую операционную систему и пользоваться утилитами в нем как переносными приложениями. В этом случае не забывайте запуска требуемые утилиты непосредственно из каталога пакета.

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

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

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

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

xperf: warning: This system is not fully configured for x64 stack tracing. Please modify the registry under: HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management and set the value: DisablePagingExecutive (REG_DWORD) = 1 Then reboot before retrying tracing. Note: Tracing has been enabled, this is just a warning.

xperf: warning: This system is not fully configured for x64 stack tracing. Please modify the registry under: HKLM\System\CurrentControlSet\Control\Session Manager\Memory Management and set the value: DisablePagingExecutive (REG_DWORD) = 1 Then reboot before retrying tracing. Note: Tracing has been enabled, this is just a warning.

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

xperf: error: NT Kernel Logger: Cannot create a file when that file already exists. (0xb7).

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

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

Что грузит процессор? Мы все ближе подходим к ответу на этот вопрос. После того, как мы завершили трассировку, переходим в целевую папку, заданную нами в опциях запуска утилиты 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 .

По желанию можно сконфигурировать путь к серверу символов Microsoft для получения подробной информации об именах вызываемых функций. Естественно, имена будут сопоставлены только с теми функциями, для которых имеются (то есть для большинства сторонних программ мы имен не получим). Для подключения символов необходимо зайти в меню Trace , далее в раздел Configure Server Paths , потом прописать в параметр _NT_SYMBOL_PATH значение srv*c:\symbols*http://msdl.microsoft.com/download/symbols . Затем, в меню Trace включить опцию Load Symbols . Но будьте осторожны, символы будут подгружаться из сети Интернет для каждого модуля, обнаруженного в стеках вызовов, объем загружаемых данных иногда бывает достаточно большим, в этом случае интерфейс может подвиснуть до окончания полной загрузки символов. Последний раз процедура заняла у меня порядка 10 минут, в течении которых окно анализатора не отвечало.

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

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

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

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

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

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

Выводы

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

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

У вас постоянно загружен процессор и сильно тормозит компьютер или ноутбук? И при этом – в режиме простоя? Большая загрузка ЦП (центрального процессора) – это одна из наиболее распространенных на сегодня проблем. И с ней постоянно сталкиваются пользователи ПК и ноутбуков.

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

Эти советы – универсальны, поэтому можете применять их на Windows 7, 8, 10 и XP. Модель процессора на ноутбуке или компьютере тоже не имеет особого значения.

Для начала нужно запустить диспетчер и посмотреть, на сколько процентов загружен процессор на вашем ПК. Для этого нажмите Ctrl+Shift+Del и обратите внимание на пункт «Загрузка ЦП» (он находится внизу).

В принципе, это значение может прыгать. Но не сильно. Например, у Core i5 в режиме простоя (или при включенном браузере) грузится на 2-8%. И это норма. Хотя на слабых процессорах (например, 2-ядерных Core 2 Duo) нагрузка может быть уже 10-20%. Здесь все зависит от конкретной модели ЦП, установленной на компьютере или ноутбуке.

Если же процессор загружен на 50 или 100 процентов, то это явно перебор. Чтобы посмотреть, почему так сильно грузится процессор на Windows 7, перейдите на вкладку «Процессы», а затем нажмите на поле «ЦП». Это отсортирует список в порядке убывания.

На скриншоте ниже видно, что ЦП грузит только плагин Flash Player (из-за включенного браузера). Но не сильно, поэтому в данном случае это не критично.

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

А еще обязательно обратите внимание на неизвестные процессы, из-за которых процессор загружен на 50 процентов (или выше). Особенно, если вы их первый раз видите, и они грузят ЦП как минимум на 20%. Вполне возможно, что это вирусы.

Что делать, если процессор загружен без причин

Не нашли никаких процессов в диспетчере, а ЦП по-прежнему сильно грузится в простое? Для начала можно нажать кнопку «Отображать процессы всех пользователей». Обычно это не помогает, но, возможно, в списке появятся новые пункты.

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

1. Запустите утилиту.
2. Нажмите на столбец «CPU», чтобы отсортировать процессы в порядке убывания нагрузки.
3. Смотрите, почему сильно грузится процессор.

На скриншоте выше видно, что всему виной процесс Interrupts (системные прерывания). Именно он нагружает процессор на 18% в режиме простоя. Хотя может грузить на 50 и даже на все 100 процентов!

Исправить подобную проблему крайне сложно. А все потому, что такая большая нагрузка ЦП может возникать из-за:

• драйверов на компьютере или ноутбуке;
• вирусов;
• неправильного режима работы жесткого диска;
• проблем с периферийной техникой (принтерами, сканерами, HDD-накопителями и пр.).

Чаще всего сильная загрузка центрального процессора возникает из-за драйверов. Чтобы проверить это, и посмотрите, есть ли нагрузка на ЦП. Если нет – то, скорее всего, проблема кроется именно в драйверах.

Наиболее простой способ исправить ее – . А потом поочередно устанавливать драйвера на компьютер или ноутбук и проверять загрузку ЦП после каждого из них. Так можно быстро найти виновника.

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

А еще совсем не лишним будет использование специальных утилит для поиска вредоносных программ и рекламных вирусов (adware, malware).

Некорректная работа жесткого диска тоже может повлиять на то, что процесс будет сильно загружен. Особенно, если он работает в режиме PIO (должен быть установлен режим DMA). Это нужно обязательно проверить и исправить при необходимости.

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

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

Процессор постоянно загружен на 100 процентов в Windows 7

Есть еще одна довольно распространенная проблема, которая часто встречается на Windows 7. Заключается она в том, что на многих ПК и ноутбуках процессор постоянно загружен на 100 процентов в режиме простоя (т.е. даже на рабочем столе). И если открыть диспетчер задач, то там можно увидеть процесс svchost.exe, который дублируется несколько раз.

Причина здесь кроется в автоматическом обновлении Windows 7. Дело в том, что обновления сейчас выпускают только для Виндовс 8 и 10. Для Windows 7 они, конечно же, не подходят, а потому работают некорректно. Именно по этой причине на Windows 7 процессор грузится на 100 процентов.

Чтобы это исправить, нужно просто отключить автоматическое обновление. Для этого:

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

Вместо заключения

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

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

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

Симптомы высокой загруженности ЦП

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

• Команда show processes cpu выдает высокое значение в процентах
• Медленная работа
• Службы маршрутизатора не отвечают, например:
  • задержка ответа Telnet или невозможно получить доступ к маршрутизатору по протоколу Telnet
  • медленный ответ на консоли
  • медленный ответ на запрос команды ping или вообще нет ответа
  • маршрутизатор не отправляет обновления маршрутизации другим маршрутизаторам

Первоначальное устранение неполадок

Как только будет замечен какой-нибудь из указанных выше симптомов, выполните следующее:

• Проверьте наличие проблем, связанных с безопасностью. Как правило, высокая загрузка ЦП бывает обусловлена именно проблемами такого рода, например функционированием вредоносной программы (червя или вируса) в сети. Если последние изменения в сети производились давно, это наиболее вероятная причина высокой загрузки ЦП. Обычно для ограничения негативных последствий этой проблемы достаточно добавить строки в списки доступа.
• Убедитесь, что все команды отладки в маршрутизаторе выключены, выполнив команду undebug all или no debug all .
• Удается выполнить команды show на маршрутизаторе? Если да, немедленно начните собирать дополнительные сведения, используя эти команды.
• Маршрутизатор недоступен? Удается воспроизвести эту проблему? Если да, выключите и включите маршрутизатор, а перед воспроизведением проблемы настройте команду scheduler interval 500 . В результате выполнение процессов с низким приоритетом будет запланировано с интервалом в 500 миллисекунд, благодаря чему появится время для запуска некоторых команд, даже если ЦП используется на все 100%. На серий 7200 и 7500 используйте команду scheduler allocate 3000 1000.
• Проявляет маршрутизатор признаки высокой загрузки ЦП в течение кратких и непрогнозируемых периодов? Если да, регулярно собирайте выходные данные команды show processes cpu , которые отображают причину высокой загрузки ЦП, если она вызвана прерываниями или отдельным процессом.
• Выяснение причин и решение проблемы

Используйте команду show processes cpu , чтобы определить, чем вызвана высокая загрузка ЦП, прерываниями или процессами.

Высокая загруженность ЦП процессами

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

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

• Все журналы регистрации, за исключением журнала регистрации сведений для буферов, должны быть отключены или уровень важности протоколируемых в них сведений должен быть понижен с 7 (отладка) до 6 (информационный) или ниже при помощи соответствующей команды настройки logging destination [ уровень важности ] . Сведения о включенных журналах регистрации и уровнях важности протоколируемых в них сведений содержатся в строках заголовка выходных данных команды show logging exec.
• Размер буфера регистрации необходимо увеличить, чтобы он вмещал всю необходимую информацию. Дополнительные сведения см. в описании команды глобальной настройки logging buffered .
• Чтобы облегчить восприятие и понимание отладки, следует включить временные отметки в миллисекундах, а также дату и время. Дополнительную информацию см. в описании команды глобальной настройки service timestamps .

Команды для получения дополнительной информации

Эти команды позволяют получить дополнительные сведения о проблеме:

• show processes cpu
• show interfaces
• show interfaces switching
• show interfaces stat
• show ip nat translations
• show align
• show version
• show log

Если маршрутизатор совершенно недоступен, сначала выключите и включите его. Затем периодически собирайте выходные данные вышеуказанных команд, за исключением команды show log , результаты выполнения которой должны регистрироваться на сервере системного журнала. Выходные данные следует собирать с интервалом 5 минут. Сбор данных можно также выполнить с помощью HTTP или SNMP.

Команда show processes cpu

Это пример заголовка команды show processes cpu :

CPU utilization for five seconds: X%/Y%; one minute: Z%; five minutes: W% PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process

В следующей таблице описаны поля этого заголовка:

X Y Z W PID Runtime Invoked uSecs 5Sec 1Min 5Min TTY Process

Поле	Описание
Среднее суммарное использование за последние пять секунд (прерывания + процессы)
Среднее использование прерываниями за последние пять секунд¹
Среднее суммарное использование за последнюю минуту²
Среднее суммарное использование за последние пять минут²
Идентификатор процесса
Время ЦП, использованное процессом (в миллисекундах)
Число вызовов процесса
Время ЦП в микросекундах для каждого вызова процесса
Использование ЦП заданием за последние пять секунд
Использование ЦП заданием за последнюю минуту2
Использование ЦП заданием за последние пять минут2
Управляющий процессом терминал
Имя процесса

¹Использование ЦП на уровне процесса = X - Y
²Значения соответствуют не арифметическому среднему, а экспоненциально затухающему среднему, поэтому последние значения больше влияют на вычисляемое среднее.

Примечание: Суммарное использование ЦП не следует интерпретировать как показатель способности маршрутизатора коммутировать большее число пакетов. В маршрутизаторах Cisco 7500 универсальные интерфейсные процессоры (VIP) и процессоры маршрутизации и коммутации (RSP) не сообщают о линейном использовании ЦП. Почти половина мощности коммутации в пакетах в секунду реализуется после 90-95% загрузки ЦП.

Команда show interfaces switching

Эта команда используется для определения активных путей коммутации на интерфейсах

Ниже приведен пример выходных данных команды show interfaces switching для одного интерфейса:

RouterA#show interfaces switching

	Throttle count	0
Drops	RP	0	SP	0
SPD Flushes	Fast	0	SSE	0
SPD Aggress	Fast	0		0
SPD Priority	Inputs	0	Drops	0
Protocol	Path	Pkts In	Chars In	Pkts Out	Chars Out
Other	Process	0	0	595	35700
	Cache misses	0
	Fast	0	0	0	0
	Auton/SSE	0	0	0	0
	IP Process	4	456	4	456
	Cache misses	0
	Fast	0
	Auton/SSE	0	0	0	0
IPX	Process	0	0	2	120
	Cache misses	0
	Fast	0	0	0	0
	Auton/SSE	0	0	0	0
Trans. Bridge	Process	0	0	0	0
	Cache misses	0
	Fast	11	660	0	0
	Auton/SSE	0	0	0	0
DEC MOP	Process	0	0	10	770
	Cache misses	0
	Fast	0	0	0	0
	Auton/SSE	0	0	0	0
ARP	Process	1	60	2	120
	Cache misses	0
	Fast	0	0	0	0
	Auton/SSE	0	0	0	0
CDP	Process	200	63700	100	31183
	Cache misses	0
	Fast	0	0	0	0
	Auton/SSE	0	0	0	0

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

Process Cache misses Fast Auton/SSE

Поле	Описание
Обработанные пакеты. Это могут быть пакеты, предназначенные для маршрутизатора, или пакеты, для которых не было записей в кэш-памяти быстрой коммутации.
Пакеты, для которых не было записей в кэш-памяти быстрой коммутации. Будет обработан первый пакет для этого пункта назначения (или поток – зависит от типа настроенной быстрой коммутации). Все последующие пакеты будут быстро коммутироваться, если только быстрая коммутация не будет специально отключена на исходящем интерфейсе.
Пакеты, обработанные быстрой коммутацией. Быстрая коммутация включена по умолчанию.
Пакеты, обработанные автономной коммутацией; коммутацией с помощью кремниевых процессоров или распределенной коммутацией. Доступны только на маршрутизаторах Cisco серии 7000 с процессором коммутации или кремниевым процессором коммутации (для автономной коммутации или коммутации с использованием кремниевых устройств соответственно), либо на маршрутизаторах Cisco серии 7500 с процессором VIP (для распределенной коммутации).

Команда show interfaces stat

Эта команда является объединенной версией команды show interfaces switching. Ниже приведен пример выходных данных для одного интерфейса:

RouterA#show interfaces stat

Ethernet0	Switching path	Pkts In	Chars In	Pkts Out	Chars Out
	Processor	52077	12245489	24646	3170041
	Route cache	0	0	0	0
	Distributed cache	0	0	0	0
	Total	52077	12245489	24646	3170041

Выходные данные команды show interfaces stat на разных платформах отличаются: они зависят от доступных и настроенных коммутируемых путей.

Команда show ip nat translations

Команда show ip nat translations служит для отображения активных на маршрутизаторе трансляций преобразования сетевых адресов (NAT). Каждая активная трансляция генерирует прерывания ЦП и влияет на суммарное использование ЦП маршрутизатора. Большое число трансляций может повлиять на производительность маршрутизатора.

Ниже приведен пример выходных данных команды show ip nat translations:

router#show ip nat translations Pro

Inside global	Inside local	Outside local	Outside global
---	172.16.131.1	10.10.10.1	---

Команда show align

Эта команда доступна только на платформах на базе RISC-процессоров с сокращенным набором команд. На этих платформах ЦП может корректировать нарушения выравнивания для чтения и записи в памяти. Ниже приведен пример выходных данных:

Alignment data for:
4500 Software (C4500-DS40-M), Version mis-aligned RELEASE SOFTWARE (fc1)
Compiled Tue 31-Mar-98 15:05 by jdoe

Total Corrections 33911, Recorded 2, Reads 33911, Writes 0

Initial Initial
Address Count Access Type Traceback
40025F4D 15561 16bit read 0x606F4A7C 0x601C78F8 0x6012FE94 0x600102C0
40025F72 18350 32bit read 0x606FB260 0x6013113C 0x600102C0 0x60010988

Команда show version

В целях отслеживания проблем высокой загрузки ЦП, важной частью выходных данных этой команды является версия программного обеспечения Cisco IOS, платформа, тип ЦП и время работы маршрутизатора. Щелкните эту ссылку, чтобы ознакомиться с подробным описанием команды show version.

Команда show log

Эта команда отображает содержание сообщений журнала регистрации сведений о буферах.

Есть вопросы?
Обращайтесь в "Аквилон-А", чтобы узнать подробности и получить именно то, что вам требуется.