• Перевод

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

В этой статье объясняются общие симптомы и причины высокой загруженности ЦП в маршрутизаторах 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

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

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

Когда ваш комп тормозит, это мягко говоря не очень хорошо — лично меня это очень нервирует. Поэтому нужно в срочном порядке понять, что именно грузит комп, какая программа.

На самом деле, сделать это очень просто и все инструменты для этого у нас есть в самой Windows 10 (да и в старых версиях они также есть).

Когда вы поняли, что это за программа — то логично ее безжалостно «вырубить», и освободить этим компьютер от нагрузки. Но! Не каждую программу можно так завершать, если это системная, то лучше не трогать а просто сделать перезагрузку, если это знакомая вам программа — то можно и завершить ее, если ничего важного в программе не делается.

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

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

Запускаем диспетчер (кликните по панели задач правой кнопкой мыши):

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

То есть таким способом, вы можете узнать, какая прога нагружает ваш комп. А вот так, вы можете ее отключить:

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

Теперь второй способ, он более информативный — это при помощи списка процессов, в том же диспетчере идем на вкладку Подробности , и там будет список процессов. Там также нужно нажать на колонку ЦП :

И мы опять видим виновника — это процесс WinRAR.exe , но, тут плюс в том, что в колонке Имя пользователя вы также будете видеть от какого имени запущен процесс! То есть если от вашего (а не от Системы , LOCAL SERVICE , DWM-1 , NETWORK SERVICE или подобного), и если этот процесс/прога ничего особо важного не делает — можно выключать. Если не от вашего имени, то есть это было запущено самой системой — то лучше не трогать, а сделать перезагрузку.

Чтобы завершить работу проги, просто нажмите правой кнопкой мыши и выберите там Снять задачу :

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

Svchost.exe (сервис-хост) – файл и процесс операционных систем семейства Windows. Его задача – загружать и выполнять внутренние службы из динамически подключаемых библиотек (файлов с расширением.dll), обеспечивая работоспособность практически всех компонентов операционной системы. Образно говоря, svchost.exe – это печень, почки и легкие Windows, без которых ее существование немыслимо. Но почему эти «жизненно важные органы» иногда создают нам столько проблем?

Сегодня поговорим о том, что делать, если svchost.exe грузит процессор, не давая нормально работать на компьютере.

Причины загрузки системы процессом svchost

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

• Вирусное заражение.
• Слишком высокая загруженность сети, например, множеством открытых слотов в uTorrent.
• Ошибки драйверов устройств (звукового, сетевого и т. д.), так как последние тесно взаимодействуют с системными службами.
• Повреждение файлов операционной системы (в частности, самого сервис-хоста и различных динамических библиотек).
• Ошибки системных служб.
• Неисправность аппаратной части ПК.

Иногда подобное бывает следствием неудачной пиратской активации Windows (не все активаторы одинаково полезны) и взлома программ.

Как определить, какая служба грузит сервис-хост

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

В зеленой рамке на скриншоте показан список служб одного процесса svchost.

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

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

• Откройте приложение «Службы » (кнопка открытия находится внизу одноименной вкладки диспетчера задач).

• Отключите первую службу из списка грузящего сервис-хоста: откройте через меню правой кнопки ее свойства и выберите из списка «Тип запуска » «Вручную » или «Отключена ».

• Перегрузите компьютер. Если проблема не ушла – снова запустите эту службу и отключите следующую.

Проблемная служба обнаружена, что дальше?

Дальше действуйте по ситуации. Если сбой вызывает второстепенный компонент, например, Superfetch (довольно часто создает проблему пользователям Windows 8 и 10), просто оставьте его отключенным. Если служба связана с оборудованием (аудио, сеть и т. д.) – попробуйте обновить или откатить драйвер устройства. При проблемах с Центром обновления Windows (часто встречается на «семерках» и XP), в 90% случаев помогает отключение проверки обновлений. Однако полный отказ от установки обновлений системы – это большая брешь в безопасности Виндовс, поэтому лучше переключите ее в ручной режим.

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

В отдельных случаях помогает очистка папки \Windows\Prefetch , где хранятся файлы трассировки Префетчера – системного компонента, который ускоряет загрузку системы и программ.

Как разгрузить сеть

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

Снизить загрузку процессора сетевыми компонентами помогает:

• уменьшение количества одновременных закачек и раздач торрентов;
• запрет доступа к Интернету программам, для которых это не обязательно (особенно если их много);
• завершение работы сетевых программ, когда они не используются;
• очистка временных папок (temp) – в них могут находиться недокачанные файлы, которые приложения-качалки пытаются догрузить до конца;
• проверка антивирусом на наличие сетевых червей;

Еще одна «болезнь» довольно продолжительное время терзала Виндовс 7. При ней загруженность ЦП процессом svchost достигала 100% и снижалась только при отключении сети. Причина крылась в безудержном «размножении» виртуальных туннельных адаптеров Microsoft 6to4 , которых иногда создавалось несколько сотен.

Чтобы проверить, не ваш ли это случай, откройте диспетчер устройств, зайдите в меню «Вид » и отметьте флажком «Показать скрытые устройства ». Следом разверните список сетевых адаптеров. Все клоны «Microsoft 6to4», если есть, находятся там.

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

После распаковки devcon на жесткий диск запустите от имени администратора командную строку и выполните инструкцию C:\devcon.exe remove *6to4* (вместо C:\ укажите ваш путь к devcon.exe). Чтобы ситуация не повторялась, обновите операционную систему.

Сегодня проблема с адаптерами 6to4 уже устранена разработчиками и встречается только у тех, кто не устанавливает обновления Виндовс.

А если это вирус? Как отличить вредоносный svchost от нормального

Вредоносная программа может:

• Создать на жестком диске свою копию под именем svchost.exe, которая будет размещаться где угодно, кроме каталога \Windows\System32 , поскольку в нем находится одноименный системный файл. То есть, замаскироваться под системный процесс.
• Внедрить свои динамические библиотеки в один из легальных хост-процессов.
• Модифицировать (пропатчить) системный файл svchost.exe, поместив в его тело собственный исполняемый код.

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

Большинство нормальных хост-процессов выполняется от имени системы, network service и local service. До выпуска Windows 8 любой сервис-хост, запущенный от имени пользователя, автоматически признавался вирусом, но сейчас это справедливо только для Windows 7 и ее предшественниц. В «восьмерке» и «десятке» один сервис-хост, работающий от имени пользователя, является нормой.

На то, что хост-процесс запущен или используется вирусом, указывает хотя бы один из признаков:

• Файл хост-процесса находится НЕ в папке \Windows\System32.
• В процессе работает неизвестная служба или в него загружена несистемная библиотека (.dll).

• На Windows XP-7 хост-процесс запущен от имени пользователя, а на Windows 8-10 присутствует больше одного хост-процесса от имени пользователя.
• Родительским процессом (Parent) нормального сервис-хоста всегда является приложение Services.exe. При заражении вирусом вместо него может всё, что угодно.

На скриншотах показан Process Explorer , запущенный от имени администратора. Для просмотра списка.dll, загруженных в сервис-хост, выделите последний кликом мыши и нажмите на клавиатуре Ctrl+D. Чтобы узнать его родительский процесс, нажмите кнопку «Properties » в верхней панели программы и откройте вкладку «Image ».

Что делать, если svchost.exe заражен вирусом

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

Как проверить на ошибки системные файлы

Большая часть динамических библиотек, откуда сервис-хост загружает службы, является собственным файлами Виндовс, меньшая – компонентами драйверов устройств. Ошибки файлов системы поможет исправить консольная утилита sfc.exe.

Запустите от администратора командную строку и выполните инструкцию sfc / scannow . Параметр /scannow означает: «немедленно проверить и заменить все поврежденные файлы из кэшированной копии».

Результаты будут показаны после окончания проверки в этом же окне.

Что делать, если ничего не помогает

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

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

Ещё на сайте:

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

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

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

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

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

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

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

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

Какие могут быть последствия от сильной нагрузки процессора?

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

— Медленная работа компьютера — при сильной нагрузке окна будут открываться очень медленно. Будут видны всевозможные «артефакты» при открытии. И просто будет невозможно использовать компьютер.

Как посмотреть чем нагружен процессор?

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

Диспетчер задач

Чтобы увидеть процент нагрузки на процессор, откройте диспетчер задач и во вкладке «Производительность» будет выявлен график, который показывает нагрузку на каждое ядро, а также, на весь процессор.

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

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

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

На операционной системе Windows 8 функция автозапуска расположена в более удобном месте — диспетчере задач.

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

Вирусы

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

Антивирусы

Как бы это странно не выглядело, но антивирусы могут сильно нагружать процессор. Рекомендуется не использовать антивирусы, а пользоваться лечащими утилитами раз в месяц. Они не требуют установки, но все же эффективнее, чем постоянно работающий антивирус (пример такой утилиты — dr.Web CureIt!).

Нестабильно работает система охлаждения

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

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