Если у вас при работе в Windows 7 наблюдается предположительно беспричинная высокая загрузка CPU и, следовательно, заметная потеря производительности, на то может быть несколько разных причин. Здесь мы рассмотрим три подхода к решению проблемы.
Высокая загрузка процессора из-за вируса
Возможно, на вашем компьютере завелся вирус. Чтобы проверить это, вы можете сделать следующее:
Процессор загружен на 100%, что делать? ️ ⏲
- Откройте «Диспетчер задач». Для этого используйте сочетание нажатых клавиш [Ctrl]+[Alt]+[Del], а затем выберите пункт «Открыть диспетчер задач».
- В появившемся окне выберите вкладку «Процессы» и отсортируйте список, кликнув на заголовок колонки «ЦП».
- Если в данный момент на вашем ПК не выполняется никаких работ, то ни один из процессов не будет иметь высокой нагрузки на Таким образом, попытайтесь найти процесс, нагружающий процессор. Если такового в списке не обнаружится, то скорее всего на вашем компьютере есть вирус, так как вредоносное ПО умеет прятаться от диспетчера задач.
- Запустите проверку с помощью антивирусного сканера, чтобы найти вирус.
Высокая загрузка процессора из-за программ в автозапуске
Возможно, высокую нагрузку на CPU обеспечивают программы, автоматически запускающиеся вместе с Windows.
- Повторите первое и второе действие из предыдущего абзаца, чтобы открыть «Диспетчер задач» на вкладке «Процессы».
- Найдите процессы, которые нагружают CPU особенно сильно.
- Нажмите клавиши [Win]+[R] и введите в открывшемся окне команду «msconfig».
- Перейдите на вкладку «Автозагрузка» и посмотрите, есть ли там процесс, который в настоящее время сильно нагружает
- Вы можете исключить его из списка программ, автоматически запускающихся при старте Windows, убрав галочку слева от названия процесса. Но будьте внимательны: из числа автоматически запускающихся программ нельзя убирать антивирусное программное обеспечение и утилиту для резервного копирования. При этом, конечно, иногда они будут отнимать значительную часть производительности вашего компьютера.
Высокая загрузка процессора из-за svchost.exe
Процессор Загружен на 100? Как Снизить Загрузку и Увеличить FPS в Играх на Windows 10
Из-за неправильной установки библиотек в AppData может запуститься бессмысленный, но интенсивно нагружающий CPU процесс: svchost.exe. Не следует путать его с svchost.exe, принадлежащим непосредственно Windows.
- Повторите первое и второе действие из предыдущего абзаца.
- Если на самом верху находится процесс «svchost.exe», сделайте следующее.
- Нажмите клавиши [Win]+[R] и введите в открывшемся окне команду «%appdata%».
- Найдите в появившемся окне «Проводника» папку, которая называется «dll» и удалите, если он существует, файл «svchost.exe».
- В качестве альтернативы вы можете скачать программу WinFuture, так как высокая нагрузка на процессор может быть вывана ошибками в работе функции обновлений операционной системы.
- Помощь в этом деле предлагает утилита WinFuture Update Pack, которую вы можете скачать как в полной версии, так и в качестве апгрейда.
Крайний выход: больше производительности благодаря новому CPU
Если все вышеприведенные советы не помогли, есть вероятность, что ваш процессор просто является слишком старым и слабым для Windows 7. В этом случае вам нужно подумать над приобретением нового CPU.
- Разумеется, это не должен быть сразу Intel i7 за 80 000 рублей. В нашем рейтинге CPU вы можете найти хорошие процессоры начального уровня, которые стоят даже меньше 2000 рублей.
- Геймерам и пользователям, работающим с графикой, имеет смысл присмотреться к моделям среднего класса. К их числу принадлежит, например, AMD FX-9370, который стоит менее 15 000 рублей.
Чтобы получить еще больше информации о работающих на вашем компьютере процессах, вы можете воспользоваться утилитой «Extended Task Manager». Кроме того, перед тем, как приступать к поиску решения проблемы, вы должны проверить, не выбраны ли в «Параметрах электропитания» режимы «Сбалансированный» или «Экономия энергии» вместо «Высокая производительность».
Фото: компании-производители
Источник: ichip.ru
Тест: как загрузить процессор на 100 процентов
Некоторые могут спросить, зачем загружать процессор, если наоборот требуется снизить нагрузку? На самом деле это нужно для проверки железа, чтобы узнать о том, эффективна ли работа самого процессора, системы охлаждения и других параметров при максимальной загрузке.
Как загрузить процессор на 100%?
Итак, все, что необходимо сделать – открыть блокнот и вписать туда две строки:
| While True Wend |
Сохраните файл с именем “loop.vbs”. Заметьте, что расширение тоже нужно написать, также и кавычки. Если так не сделать, то у вас будет простой текстовый файл, который ничего не сделает.
Теперь запустите диспетчер задач, для этого нажмите кнопки Esc+Shift+Ctrl и перейдите на вкладку «Производительность». Там нажмите правой кнопкой мыши по графику и выберите пункт «Изменить график», а потом нажмите на «Логические процессоры». Смотрим, сколько их у нас.
Теперь запускаем наш созданный файл loop.vbs столько раз, сколько у нас логических процессоров. В моем случае нужно запустить 4 раза. После этого действия вы увидите загрузку процессора под 100%.
Для завершения проверки данного скрипта перейдите в диспетчере устройств на вкладку «Подробности», найдите там процесс wscript.exe и отключите их.
Вот и все, что нужно знать о загрузке процессора до 100%. Конечно, у нас еще будет статья, как наоборот снизить нагрузку.
Источник: computerinfo.ru
Вы неверно измеряете загрузку процессора
Та метрика, которую мы называем «загрузкой процессора» на самом деле многими людьми понимается не совсем верно. Что же такое «загрузка процессора»? Это то, насколько занят наш процессор? Нет, это не так. Да-да, я говорю о той самой классической загрузке 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, то ваше приложение страдает не столько от ожидания данных, сколько от чрезмерного количества выполняемых инструкций. Ищите более эффективные алгоритмы, не делайте ненужной работы, кэшируйте результаты повторяемых операций. Применение инструментов построения и анализа Flame Graphs может быть отличным способом разобраться в ситуации. С аппаратной точки зрения вы можете использовать более быстрые процессоры и увеличить количество ядер.
Как вы видите, я провёл черту по значению IPC равному 1.0. Откуда я взял это число? Я рассчитал его для своей платформы, а вы, если не доверяете моей оценке, можете рассчитать его для своей.
Для этого напишите два приложения: одно должно загружать процессор на 100% потоком выполнения инструкций (без активного обращения к большим блокам оперативной памяти), а второе должно наоборот активно манипулировать данным в ОЗУ, избегая тяжелых вычислений. Замерьте IPC для каждого из них и возьмите среднее. Это и будет примерная переломная точка для вашей архитектуры.
Что инструменты мониторинга производительности на самом деле должны показывать
Я считаю, что каждый инструмент мониторинга производительности должен показывать значение IPC рядом с загрузкой процессора. Это сделано, например, в инструменте tiptop под Linux:
tiptop — [root] 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 (или чего-то аналогичного) непосредственно рядом с загрузкой процессора, что даст пользователю полное понимание ситуации. Имея все эти данные, разработчики могут предпринять некоторые меры по оптимизации своего кода именно в тех аспектах, где это принесёт наибольшую пользу.
- Блог компании Инфопульс Украина
- Высокая производительность
- Анализ и проектирование систем
- Системное программирование
- Разработка под Linux
Источник: habr.com