• Перевод

Та метрика, которую мы называем «загрузкой процессора» на самом деле многими людьми понимается не совсем верно. Что же такое «загрузка процессора»? Это то, насколько занят наш процессор? Нет, это не так. Да-да, я говорю о той самой классической загрузке 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 ;
  • видеть стеки вызовов модулей, что намного глубже позволяет погрузиться в изучение сбоя.

Загрузка центрального процессора является одной из самых распространенных и сложных проблем. 100% работ процессора отбирают непонятные службы и процессы. Это делает использование компьютера крайне сложным. Почему так происходит? Попробуем разобраться…


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

Распространенные причины увеличения нагрузки на ЦП

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

— нарушения в функционировании системы;
— перегрев процессора;
— недостаточное охлаждение.

Как выявить проблему?

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

Как определить программу, которая нагружает процессор?

Прежде всего, если компьютер вдруг стал плохо реагировать на команды и подтормаживать, нужно открыть диспетчер задач. Для выполнения данного действия можно использовать комбинации клавиш Ctrl+Alt+Del или Ctrl+Shift+Esc. Можно также вызвать в панели задач контекстное меню и найти соответствующий пункт. В открывшемся окне необходимо выбрать подробное представление. Появятся вкладки, среди которых необходимо выбрать «Процессы». В данной вкладке необходимо посмотреть, когда происходит загрузка процессора на 100%.

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

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

Сбои в работе системы

Ранее описанный метод не позволяет точно определить причину, по которой процессор загружается на 100%. Что предпринять в данном случае? В диспетчере задач часто можно увидеть ситуацию, когда вся нагрузка приходится на пункт «Бездействие системы». Снять задачу в этом случае не получится. Рекомендуется запустить утилиту, которую бесплатно распространяет корпорация Microsoft. Утилита Process Explorer позволяет получить расширенную информацию, показанную в диспетчере задач. В данном случае загрузка процессора на 100% может возникать из-за системных прерываний. В программе они обозначаются как Interrupts. Сложно сказать, в чем заключается причина подобного поведения, если не перейти к решительным действиям.

Что может нагружать процессор?

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

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

Перегрев и скопление пыли

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

В процессе работы компьютера могут происходить самые разные неприятности, но при этом далеко не все пользователи знают, как их устранить. Одной из наиболее распространенных проблем является загрузка ЦП 100%, когда компьютер в буквальном смысле загружен «под завязку» и перестает нормально функционировать.

В чем проблема?

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

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

Но такие ситуации зачастую единичны, и главная причина чаще всего кроется в другом.

Что еще может быть?

Если вы не знаете, что делать, если ЦП загружен на 100%, попробуйте сделать следующее:

  1. Откройте «Диспетчер задач».
  2. Нажмите вкладку «Процессы».
  3. Отфильтруйте все процессы по параметру «ЦП».
  4. Посмотрите, какие из них потребляют больше всего мощности вашего процессора и, если есть возможность, отключите их.

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

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

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

Основные причины максимальной загрузки

Причин максимальной загрузки ЦП на 100% в Windows XP, 7, 8, 10 может быть несколько и у каждой свои пути решения. Наиболее распространённая причина – это потребление определённой программой или службой всех ресурсов процессора. Так же это могут быть сбои в работе службы из-за чего она начинает вести себя не стабильно.

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

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

Определяем программу нагружающую процессор

Чтобы снизить нагрузку на ЦП, можно воспользоваться Диспетчером задач . Попасть в него можно разными способами : нажать одновременно Ctrl+Shift+Esc или Ctrl+Alt+Delete или же зайти через меню пуск в контекстное меню панели задач и там уже найти диспетчер.

Когда диспетчер задач открыт, необходимо перейти на вкладку «Процессы », в которой будут отображены процессы и службы системы. Для удобства их можно отсортировать, нажав вверху на столб «ЦП » или «Процессор » (в разных версиях Windows по разному).

И после этих манипуляций можно увидеть, какая программа или служба нагружает ЦП. Зачастую бывает, что «тяжёлые» программы (которые потребляют большое количество ресурсов ПК) после закрытия оставляют остаточные службы или не корректно завершенные приложения, тем самым влияя на работоспособность компьютера. Очень часто таким «грешат» браузеры. Кроме этого часто видео в высоком качестве, с которыми просто не справляется ПК, могут грузить и тормозить работу.

Решить это можно щёлкнув ЛКМ (левой кнопкой мыши) по приложению, которое потребляет ЦП и нажать «Снять задачу », тем самым удалив программу из ресурсов ПК. Тут следует быть осторожными, потому что есть вероятность завершить какую-то системную службу и тогда придётся вручную перезагружать компьютер.

Загрузка процессора без причины

Бывает, что в стандартной утилите «Диспетчере задач» не видно процессов, которые нагружают ЦП, но процессор все равно загружен на 100 процентов без причины. В таких случаях можно обратится к сторонним программам .

Скачайте и запустите программу AVZ. Перейдите в «Сервис/Диспетчер процессов» там будут показаны все процессы запущенные на компьютере. Главное преимущество AVZ в том, что программа помечает системные процессы зелёным цветом. Т.е. следует присмотреться нет ли процесса svchosts.exe, который окрашен в чёрный цвет.

Если же никаких сторонних процессов не обнаружено, то можно попробовать отключить автоматическое обновление Windows.

Чтобы отключить обновления, нужно попасть во вкладку «Службы », проще всего нажать Win+R, в появившемся окне написать services.msc и нажать «Ок». В открывшемся окне найти строку «Центр обновления Windows », щёлкнуть на ней дважды мышкой и выбрать «Тип запуска» — Отключена, и ниже нажать кнопку «Остановить». Затем сохраняем настройки и перезапускаем ПК.

Нагрузка на ЦП из-за перегрева

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

Чтобы узнать температуру ЦП следует воспользоваться сторонними программами, например Aida 64 .

Перегреваться компьютер может по нескольким причинам :

  1. Загрязнение . Компьютер или ноутбук требует постоянной очистки (раз в 6-12 месяцев), потому что за время использования в нём скапливается пыль, которая ухудшает работу кулеров и теплопередачу радиатора, тем самым способствуя перегреву.
    Решение : отнести компьютер в сервисный центр для его очистки или же самостоятельно открыть боковую крышку и аккуратно, но тщательно удалить всю скопившуюся пыль. (Если вы владелец ноутбука, то придётся нести в сервисный центр)
  1. Неисправности кулера . Главной задачей кулера является непрерывная подача холодного воздуха на радиатор для охлаждения ЦП. В случае его неисправности компьютер начинает сильно перегреваться. Убедиться в неисправности можно самостоятельно, следует открыть боковую крышку компьютера и посмотреть нормально ли вращается кулер (нет ли каких-то скрипов, потрескивание)
    Решение : Если кулер действительно неисправен следует немедленно обратится в сервисный центр для последующей его замены.
  1. Высокая температура в помещении . Эта проблема очень актуальна в летнее время года, дома и на улице жара, следовательно, кулер будет затягивать горячий воздух. Из-за этого его эффективность в плане охлаждения существенно падает.
    Решение : Можно самостоятельно открыть боковую крышку компьютера и направить туда обычный вентилятор. Для ноутбуков выпускают специальные подставки с охлаждением.

Устаревший ПК

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

Если при запуске стандартного приложения (браузер, paint, просмотр фотографий) загрузка ЦП становится 50% или 100% и не уменьшается, то скорее всего пришло время обновлять конфигурацию ПК.

Приложения в автозагрузке

Многие пользуются ПК годами без переустановки Windows и очистки её от программ. С течением времени и установкой тех или иных приложений автозапуск системы забивается и при загрузке ОС загружаются программы, которыми человек уже давно не пользуется. Из-за этого может быть постоянно загружен ЦП, чтобы этого избежать следует очистить «Автозагрузку»

Существует популярная утилита CCleaner , с её помощью можно убрать программы , которыми давно не пользуетесь, оставив только самые актуальные и антивирус.