Системные прерывания грузят процессор в Windows 10
В диспетчере задач Windows 10 вы можете обнаружить, что процесс Системные прерывания сильно грузит процессор, иногда до 100%. Нет точного определения, что может быть виновников высокой нагрузку, так как этот процесс всего лишь посредник, который подбрасывает ЦП полученные инструкции, а процессор останавливает текущую работу и начинает их обрабатывать. По этой причине и происходит загрузка ЦП, которую чаще всего можно заметить в слабо частотных процессорах.
Что такое системные прерывания? К примеру, есть директор ЖКХ (процессор), в ЖКХ сидит диспетчер (системные прерывания), который принимает заявки от людей (оборудование, программы). Когда народ начинает массового жаловаться и оставляет заявки диспетчеру, который в свою очередь отправляет их директору, то директор останавливает текущие работы и начинает обрабатывать заявки.
Нормальной нагрузкой на ЦП, процессом системные прерывания, считается до 5%, если больше, то имеются проблемы. Никогда не отключайте процесс «Системные прерывания» вручную, это может нарушить еще больше работу вашей системы. Давайте разберем способы, как исправить, когда системные прерывания грузят процессор в Windows 10.
Важно: Откройте диспетчер задач Ctrl+Shift+Esc. Он должен быть всегда открыт, и вы должны всегда мониторить процесс «Системные прерывания», после каждого проделанного способа или определенного действия.
1. Обновление драйверов
Нажмите Win+X и выберите «Диспетчер устройств«. В диспетчере устройств, если у вас есть оборудование с желтым восклицательным знаком, значит нужно обновить для него драйвер. Также, рекомендую обновить драйвера до последних версий видеокарты и процессора, даже, если нет восклицательного знака.
2. Отключить звуковые эффекты
Нажмите правой кнопкой мыши по иконке динамика в трее около часов и выберите «Звуки«. Выберите динамики и нажмите снизу на кнопку «Свойства«. В новом окне перейдите во вкладку «Улучшения» (Enhancemrnts) и установите галочку на отключение всех звуковых эффектов. Также, если у имеется вкладка «Пространственный звук«, то перейдите в неё и отключите.
3. Отключение Magic Packet
В Windows 10 есть сетевая функция Magic Packet, которая позволяет выводить компьютер или ноутбук из спящего режима при передачи данных. Magic Packet может быть виновником системных прерываний и нагрузки на ПК.
В диспетчере устройств разверните графу «Сетевые адаптеры» и выберите тот адаптеры, через который осуществляете подключение к интернету (Ethernet и WiFi). Нажмите по нему правой кнопкой мыши и выберите «Свойства». В новом окне перейдите во вкладку «Дополнительно» и найдите в писке параметр Magic Packet и справа выберите значение Отключено. Перезагрузите систему и проверьте системные прерывания.
4. Отключение USB-контроллеров
Первым делом, если к ноутбуку или ПК подключены флешки, внешние диски, принтер, то отключите всю с USB портов, и проверьте в диспетчере задач, грузит ли процессор системные прерывания. Подождите минуты 2. Если грузит, то заходим обратно в диспетчер устройств и разворачиваем графу «Контроллеры USB«. Отключаем все USB устройства, которые можно отключить, после чего перезагружаем ПК и смотрим, решена ли проблема.
Примечание: В меню может и не быть «Отключить устройство», это сделано, чтобы вы не отключили действующую мышь и клавиатуру, но вы должны подготовиться к этому заранее и придумать альтернативный способ для повторного включения или определить мышь и клавиатуру и не отключать их.
5. Антивирусный сканер
6. Отключение устройств
Отключим по прядку устройства, которые могут быть наиболее вероятными виновниками нагрузи на процессор системными прерываниями. Не рекомендую проделывать данный способ, если слабо разбираетесь. В диспетчере устройств отключайте не важные для работы ПК устройства и смотрите каждый раз в диспетчер задач нагрузку на ЦП. Наиболее явные виновники:
Важно : Не отключайте важные системное оборудование, которое нужно для стабильной работы Windows 10.
Включите все обратно, если вы не смогли выявить виновника и следуем ниже способу.
7. Выявить задержки DPC
Постараемся выявить виновника при помощи программы LatencyMon. Переходи на сайт и скачиваем утилиту https://www.resplendence.com/downloads
Далее запускаем программу и жмем Play. Переходим во вкладку Drivers и ждем, чтобы собралось больше данных с количеством задержек. Далее нужно отсортировать DPS count, нажмите по этому слову. Драйверы с большим количеством DPC, потенциально могут вызвать большое количество прерываний. По процессу можно найти в Google, к какому драйверу он относиться, или пишите в комменты я подскажу.
Вывод:
Помните, что системные прерывания могут грузить процессор в Windows 10 не только из-за плохих драйверов или программного сбоя. В ноутбуках эта проблема может быть из-за батареи или плохого зарядного устройства. Также, это может быть плохое оборудование как оперативная память, которая нуждается в замене.
Борьба за производительность или кто отнимал процессорное время
Началось все с «Неваляшки». О том, что это такое и для чего это было надо описано тут: http://habrahabr.ru/company/oktell/blog/108726/. То есть, мы имели четыре работающих сервера call-центра, одинаково настроенных и с примерно одинаковой конфигурацией внешних и внутренних линий, пользователей и настройкой внутренней БД. На каждый из серверов со стороны оператора связи поступала равномерная звонковая нагрузка, но сервера реагировали на это по разному!
N Конфигурация сервера и операционная система
1 T1300 @ 1.66 1 Гб ОЗУ, Windows 2003 Standard Ed. R2 SP1 32 bit
2 Intel Core Duo E8400 @ 3000 4 Гб ОЗУ, Windows 2003 Standard Ed.SP1 32 bit
3 Intel Pentium 4 3GHz 2 Гб ОЗУ, Windows 2003 Standard Ed. SP2 32 bit
4 E3400 @ 2.60 2 Гб ОЗУ, Windows 2003 Standard Ed. R2 SP2 32 bit
Столкнулись с жалобами на качество связи. Причем, жаловались не на каждый звонок, а на «некоторые». Жаловались на «кваки», очень характерные для VoIP телефонии. Довольно оперативно было выяснено, что причиной появления «кваков» было непредсказуемый рост занятости процессора на одном (первом) из серверов call-центр при возрастании нагрузки. И это при всем притом, что другие сервера такой нагрузки вообще не замечали, и никакого роста нагрузки на процессор при таком же количестве вызовов не наблюдалось. Даже, несмотря на то, что первый сервер был значительно слабее всех остальных, такой картины — роста занятости процессора до 100% — наблюдаться не должно было.
Не стоит, наверное, говорить, что мы прошли стандартный путь «протирки фар», «пинания колес» и пр. В конечном итоге пришли к мнению, что ни настройки самого call-центр, ни его СУБД, на поведение сервера не влияет. Отправной точкой для понимания сущности проблемы послужил тот факт, что в диспетчере задач в списке процессов ни один из процессов не занимал процессорного времени, вместе с тем, на мониторинге быстродействия хронология загрузки процессора показывала непрерывную загрузку процессора ядра на уровне 20%.
Задались целью получить ответ на вопрос чем же занято ядро в том случае, когда нагрузки на все остальные сервисы отсутствуют. Process Explorer — штатная утилита от Microsoft — подсказала, что основным потребителем ресурсов является «Hardware Interrupts». Для дальнейшего анализа причин такого потребления была скачана другая штатная утилита от Microsoft — «Kernrate View». Как и было описано в рекомендациях по использованию, в командной строке выполнили «C:\Program Files\KrView\Kernrates\Kernrate_i386_XP.exe >> log.txt» и, спустя некоторое время, нажав Ctrl-C, остановили. Получили файл log.txt, содержащий информацию вида:
/==============================\
\==============================/
Date: 2010/12/08 Time: 1:09:14
Machine Name: RESERVCC
Number of Processors: 1
PROCESSOR_ARCHITECTURE: x86
PROCESSOR_LEVEL: 6
PROCESSOR_REVISION: 0e08
Physical Memory: 1015 MB
Pagefile Total: 2450 MB
Virtual Total: 2047 MB
PageFile1: \??\C:\pagefile.sys, 1524MB
OS Version: 5.2 Build 3790 Service-Pack: 1.0
WinDir: C:\WINDOWS
Kernrate User-Specified Command Line:
Kernrate_i386_XP.exe
Kernel Profile (PID = 0): Source= Time,
Using Kernrate Default Rate of 25000 events/hit
P0 K 0:00:36.671 (28.5%) U 0:00:09.671 ( 7.5%) I 0:01:22.343 (64.0%) DPC 0:00:29.484 (22.9%) Interrupt 0:00:00.281 ( 0.2%)
Interrupts= 136809, Interrupt Rate= 1063/sec.
Total Profile Time = 128687 msec
Total Avg. Rate
Context Switches, 609407, 4736/sec.
System Calls, 5078088, 39461/sec.
Page Faults, 119817, 931/sec.
I/O Read Operations, 11671, 91/sec.
I/O Write Operations, 209479, 1628/sec.
I/O Other Operations, 229216, 1781/sec.
I/O Read Bytes, 39981700, 3426/ I/O
I/O Write Bytes, 19240135, 92/ I/O
I/O Other Bytes, 7130204725, 31107/ I/O
— Results for Kernel Mode:
— OutputResults: KernelModuleCount = 99
Percentage in the following table is based on the Total Hits for the Kernel
Time 44651 hits, 25000 events per hit — Module Hits msec %Total Events/Sec
intelppm 27457 128685 61 % 5334149
hal 12284 128685 27 % 2386447
ntkrnlpa 2868 128685 6 % 557174
win32k 525 128685 1 % 101993
alder9xp 427 128685 0 % 82954
tcpip 254 128685 0 % 49345
Ntfs 251 128685 0 % 48762
afd 120 128685 0 % 23312
RDPDD 109 128685 0 % 21175
e1e5132 109 128685 0 % 21175
iaStor 97 128685 0 % 18844
NDIS 39 128685 0 % 7576
RDPWD 31 128685 0 % 6022
fltMgr 26 128685 0 % 5051
amon 12 128685 0 % 2331
termdd 10 128685 0 % 1942
CLASSPNP 10 128685 0 % 1942
ftdisk 7 128685 0 % 1359
ipsec 3 128685 0 % 582
Npfs 2 128685 0 % 388
USBPORT 2 128685 0 % 388
volsnap 2 128685 0 % 388
TDTCP 1 128685 0 % 194
rdbss 1 128685 0 % 194
ws2ifsl 1 128685 0 % 194
netbt 1 128685 0 % 194
watchdog 1 128685 0 % 194
PartMgr 1 128685 0 % 194
Далее определяем какой именно драйвер загружает процесс «Hardware Interrupts». В списке лога «Kernrate View» он будет верхним, и рядом в процентах будет показана его доля занимания ядра. Тут стоит обратить внимание, что проценты показывают не общий процент от загрузки системы, а процент загрузки серверного ядра драйверами.
Определили, что этим драйвером является Intelppm (Intel processor power manager). Дальше — google нам в помощь. Интернет велик, могуч и безграничен. Довольно быстро поняли, что проблема с Intelppm возникает, не так уж и часто, вместе с тем, мы были не одни столкнувшиеся с такой бедой. Результат не замедлил себя обнаружить, нашлась статья, в которой не только описывается сама проблема, но и обозначается путь ее решения (Постоянный адрес оригинала статьи тут: http://www.osp.ru/text/print/302/5818429.html)
Далее следуя рекомендациям Стивена Догерти понимаем, что intelppm, является драйвером управления электропитанием процессора, который не нужен на сервере, где питание от аккумулятора и не используется вовсе. Вариантов решений было предложено несколько: переустановка, обновление или остановка неисправного драйвера. Какой варианты выберете вы — смотрите сами, вполне логично тут следовать оригинальным рекомендациям Догерти.
Мы полезли в реестр. Данные драйвера процессора Intel находятся в разделе реестра HKEY_LOCAL_MACHINE/SYSTEM/Current Control Set/Services/intelppm. Для отключения драевера intelppm изменили значение параметра Start с 1 на 4. Специалисты Microsoft, конечно, рекомендуют делать резервную копию реестра, но мы то с вами русские люди, да и что там один параметр поменять с 1 на 4. 
Рестарт помог убедиться, что загрузка процессора в среднем находится в пределах 60-70% даже при полной(!) загрузке сервера call-центр звонками.
Очень интересно выглядит при этом диспетчер устройств: 
Жалуется, ябедничает, плачет: «Драйвер для этого устройства был отключен. Возможно, необходимые функции исполняет другой драйвер. (Код 32), Нажмите кнопку „Диагностика“, чтобы запустить мастер диагностики для данного устройства.» Но на безопасность полетов это уже не влияет 😉
Interrupts что это за процесс
Всем, у кого проблемы с постоянной высокой загруженностью процессора:
1. Скачайте Process Explorer отсюда: http://technet.microsoft.com/ru-ru/s. /bb896653.aspx
2. Запустите его, всё разверните в дереве процессов.
3. Сделайте скриншот.
4. Получившийся файл прикрепите к своему посту вложением.
Не сразу въехал в текст 🙂
График один к одному отражает процессы и не может так отличаться.
А что показывает график загрузки ядра (ShowKernelTimes)?
еще раз внимательно 🙂 прочитал текст.
Похоже система (процессор) кого-то ждет.
Может диск дефрагментировать?
Тут самое смешное: стал обновлять драйвер этого контроллера, указал путь, всё установилось, но на последней страничке мастера установки было написано, что, мол, «файл не найден. Драйвер установлен не был», но, тем не менее, устройство перестало быть нераспознанным, переместилось куда надо, и вообще никаких нареканий 😀
После этого глюк, тоже «вроде бы», исчез.
Сегодня постараюсь принести домой антивирус какой-нибудь, проверюсь. Даже если глюк и исчез, надо выяснить, что же это было, чтоб другие потом так не маялись. :fie:
Q0011er Zourg Vanya
Спасибо за помощь! 😉
Че за системный процесс interrupts? Первый раз о нем слышу. И яндекс молчит.
С какого момента это началось? Что при этом делал?
Скорее всего проблемы с каким-то устройством. В диспетчере устройств никаких неопознаных или неработающих устройств нет?
Interrupts что это за процесс
Сообщения: 52221
Благодарности: 15093
Увеличить
