Как найти программу которая грузит процессор

Данная короткая заметка будет посвящена теме обнаружения источника внезапной нагрузки на процессор. Нагрузка на процессор, ну и что? В процессе работы с операционной системой Windows внезапные тормоза являются штатной реакцией на загрузку нами «прожорливых» приложений, например открытие большого количества «тяжелых» (использующих графические объекты на странице) вкладок в браузере Internet Explorer. Тут все прогнозируемо, ибо причиной подобных проблем является работа требовательного к ресурсам приложения, которое в зависимости от специфики выполняемой задачи способно сильно нагружать процессор. Совершенно другое дело, когда нагрузка на процессор возникает сама по себе, без видимых на то причин.

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

Как удалить майнер? Загрузка ЦП 100 ПРОЦЕНТОВ ЕСТЬ РЕШЕНИЕ

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

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

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

Установка WPT

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

• C:Program FilesMicrosoft Windows Performance Toolkit ;
• C:Program Files (x86)Windows Kits8.x ;

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

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

Словил Майнер! Как удалить майнер? Загрузка ЦП 100 ПРОЦЕНТОВ

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

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

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

Для создания нагрузки мы будем использовать утилиту под названием CPUSTRES от 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:
HKLMSystemCurrentControlSetControlSession ManagerMemory 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: error: NT Kernel Logger: Cannot create a file when that file already exists. (0xb7).

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

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

• Для старых версий 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 ;
• видеть стеки вызовов модулей, что намного глубже позволяет погрузиться в изучение сбоя.

Похожие записи:

• Process Monitor — мониторинг активности процессов
• Шторм прерываний
• Восстановление реестра
• Анализ цепочки ожидания зависшего приложения
• Анализ ошибок приложения при помощи adplus и cdb

Источник: datadump.ru

Wmi Provider Host: что это за процесс, почему загружает процессор Windows 10

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

В этой подробной инструкции вы узнаете все о процессе WmiPrvSE.exe., а именно: что это за процесс, для чего он нужен и что делать, если wmi provider host загружает процессор.

Содержание:

Подробно о процессе WMI Provider Host

Задача WMI Provider Host является системным процессом для обеспечения связи и корректной работы программам. Благодаря ему утилиты получают нужные данные и параметры о системе. Если все происходит в штатном режиме и нет никаких ошибок или сбоев, то процесс wmiprvse exe, не мешает оптимальной работе устройства.

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

Однако, если WMI Provider Host грузит процессор Windows 10, можно оптимизировать работу устройства другими способами. О них мы поговорим ниже.

3 причины из-за чего процесс Wmiprvse.exe грузить процессор

WMIPrvSE в большинстве ситуаций функционирует корректно. Его даже не всегда можно увидеть в «Диспетчере задач».
Однако в некоторых случаях, другие факторы влияют на загрузку системы и процессора этой задачей.

1. Это могут быть вновь подключенные устройства. Из-за которых произошел сбой в работе процесса.
2. Установка новой версии Windows.
3. Программы, отвечающие за работу процессора, видеокарты и некоторые другие.

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

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

Перезапуск системы

Самое простое, что вы можете сделать – это перезапустить WMIPrvSE. Часто проблема уходит после этого.

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

1. Одновременно нажимаете «Win+R»
   
2. Скопировать и вставить отсюда команду: services.msc.
   
3. В списке ищите строку “Windows Management Instrumentation Service”, также она может называться “Инструментарий управления Windows”.
4. ПКМ жмете на нее и кликаете по параметру «Перезапустить».
   

Сканирование на вирусы

Если WMI Provider Host грузит процессор в Windows 10, то нельзя забывать и о том, что процесс может быть заражен вирусом. Часто вирусы принимают имена базовых задач системы.

Чтобы проверить это, можно узнать его месторасположение. Если это системный процесс и он не заражен, то адрес будет такой:

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

1. Одновременно жмете «Shift+Ctrl+Esc»
2. Ищите строку с нужным процессом и кликаете ПКМ по нему.
3. Выбираете параметр «Открыть расположение файла».
   
4. Сверяете его с указанным выше путем. Если они отличаются, то стоит проверить ПК на вирусы.
   

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

Ищем программу, которая грузит процессор через процесс Wmiprvse.exe

Инструмент «Просмотр событий» позволяет понять, какая из установленных программ вызывает нагрузку процессора и всей системы. Для того, чтобы найти и снизить активность процесса “wmiprvse exe”, вам нужно:

1. Одновременно жмете «Win+R»
   
2. В окне “Выполнить” введите команду: eventvwr.msc.
   
3. Переходите по каталогам: «Журналы приложений и служб»-«Microsoft»-«Windows»-«WMI-Activity»-«Operational».
4. Изучаете открывшиеся окно. Здесь важно проверить все строки со значением «Ошибка». Важно помнить, что часть из них есть и при стандартной работе процесса.
   
5. Кликаете по каждой ошибке и запоминаете значение графы: «ClientProcessID».
   
6. Нажатием «Shift+Ctrl+Esc»
7. В «Диспетчер задач» перейдите во вкладку «Подробности» и в столбце ИД найдите тот же номер, который был указан в ошибке.
   

Так вы узнаете, какая программа нагружает процессор через процесс Wmiprvse.exe

Второй способ узнать, какое приложение запускает нагрузку на процессор

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

Для того, чтобы процесс Wmiprvse.exe не нагружал процессор, вам нужно:

1. Одновременно нажать «Win+R» и прописать команду: Msconfig
   
2. В окне ищите столбец с названием «Службы» и активируете параметр «Не отображать службы Майкрософт».
   
3. Все остальные можете отключить с помощью специальной клавиши.
   
4. Нажатием «Shift+Ctrl+Esc» и в открывшемся окне перейдите во вкладку «Автозагрузка».
5. Деактивируете все утилиты.
   
6. Сохраняете настройки и перезапускаете систему.

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

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

Откат обновления

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

Для того, чтобы процес WMIPrvSE не грузил процессор, нужно:

1. Нажать сочетание клавиш Win + I
   
2. Нажмите на «Обновления и безопасность»
   
3. Нажмите на «Центр обновления Windows», затем выбираете строку «Просмотреть журнал обновлений».
   
4. Далее жмете на параметр «Удалить обновления».
   
5. Поочередно удаляете последнее и проверяете корректность работы ПК (для этого после каждого отката лучше проводить перезапуск Винды).
   

Проверка устройств

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

1. Необходимо открыть «Диспетчер устройств».
2. Проверяем каждое устройство (вначале недавно установленные). Для этого ПКМ жмете на оборудование и выбираете параметр: «Отключить устройство».
3. Проверяете нагрузку на систему. Продолжаете эту последовательность до тех пор, пока не найдете причину.
4. Чтобы исправить ситуацию, советуем обновить дрова для устройства, которое вызывает торможение системы.

Итак, мы рассказали о происхождении и особенностях процесса WMIPrvSE. О том, как найти причину излишней нагрузки на систему со стороны процесса “Wmi provider host”.

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

Источник: programmainfo.ru

Как найти процессы с наиболее высокой загрузкой на процессор в Linux

Мануал

Автор cryptoparty На чтение 7 мин Опубликовано 12.12.2019

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

Я считаю, что есть только два способа проверить это.

Это можно сделать с помощью команды top и команды ps.

Я хотел бы рекомендовал использовать скорее top, нежели ps.

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

Обе эти опции широко используются администраторами Linux.

1) Как найти процесс с высокой загрузкой на процессор в Linux с помощью команды top

Команда top в Linux – это лучшая и наиболее известная команда, которую все используют для мониторинга производительности системы Linux.

Команда top обеспечивает динамическое представление в реальном времени запущенных процессов в системе Linux.

Она отображает сводную информацию о системе, список процессов, в настоящее время управляемых ядром Linux.

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

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

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

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

# top -c -b | head -50 top — 12:12:52 up 57 days, 21:58, 3 users, load average: 1.50, 1.76, 1.86 Tasks: 306 total, 1 running, 216 sleeping, 0 stopped, 0 zombie %Cpu(s): 12.7 us, 4.2 sy, 0.0 ni, 81.7 id, 0.0 wa, 0.0 hi, 1.4 si, 0.0 st KiB Mem : 16400812 total, 262904 free, 3166168 used, 12971740 buff/cache KiB Swap: 0 total, 0 free, 0 used. 13559292 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 28494 root 20 0 1515256 1.3g 52140 S 43.8 8.1 7618:26 kube-apiserver —advertise-address=10.2.67.201 —allow-privileged=true —anonymous-aut+ 13148 root 20 0 162192 4520 3848 R 12.5 0.0 0:00.03 top -c -b 17334 root 20 0 1544992 132556 58240 S 6.2 0.8 4272:14 /usr/local/bin/kubelet —logtostderr=true —v=2 —node-ip=10.2.67.201 —hostname-overr+ 28432 root 20 0 10.2g 162668 84168 S 6.2 1.0 2099:34 /usr/local/bin/etcd 1 root 20 0 129568 9180 5252 S 0.0 0.1 152:29.90 /usr/lib/systemd/systemd —switched-root —system —deserialize 22 2 root 20 0 0 0 0 S 0.0 0.0 0:01.77 [kthreadd] 3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 [rcu_gp] 4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 [rcu_par_gp] 6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 [kworker/0:0H-kb] 8 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 [mm_percpu_wq] 9 root 20 0 0 0 0 S 0.0 0.0 6:30.07 [ksoftirqd/0] 10 root 20 0 0 0 0 I 0.0 0.0 131:34.14 [rcu_sched] 11 root rt 0 0 0 0 S 0.0 0.0 0:37.83 [migration/0] 13 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [cpuhp/0] 14 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [cpuhp/1] 15 root rt 0 0 0 0 S 0.0 0.0 0:36.70 [migration/1] 16 root 20 0 0 0 0 S 0.0 0.0 4:50.86 [ksoftirqd/1] 18 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 [kworker/1:0H-kb] 19 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [cpuhp/2] 20 root rt 0 0 0 0 S 0.0 0.0 0:36.68 [migration/2] 21 root 20 0 0 0 0 S 0.0 0.0 5:33.95 [ksoftirqd/2] 23 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 [kworker/2:0H-kb] 24 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [cpuhp/3] 25 root rt 0 0 0 0 S 0.0 0.0 0:35.79 [migration/3] 26 root 20 0 0 0 0 S 0.0 0.0 6:43.56 [ksoftirqd/3] 28 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 [kworker/3:0H-kb] 29 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [kdevtmpfs] 30 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 [netns] 31 root 20 0 0 0 0 S 0.0 0.0 0:13.96 [kauditd] 32 root 20 0 0 0 0 S 0.0 0.0 0:12.74 [khungtaskd] 33 root 20 0 0 0 0 S 0.0 0.0 0:00.00 [oom_reaper] 34 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 [writeback] 35 root 20 0 0 0 0 S 0.0 0.0 0:00.47 [kcompactd0] 36 root 25 5 0 0 0 S 0.0 0.0 0:00.00 [ksmd] 37 root 39 19 0 0 0 S 0.0 0.0 0:20.81 [khugepaged] 130 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 [kintegrityd] 131 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 [kblockd] 132 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 [blkcg_punt_bio] 133 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 [tpm_dev_wq] 134 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 [md] 135 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 [edac-poller] 136 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 [devfreq_wq] 137 root rt 0 0 0 0 S 0.0 0.0 0:00.00 [watchdogd]
Детали вышеупомянутой команды:

• top : это команда
• -b : Пакетный режим.
• head -50: Показать первые 50 строк в выходных данных.
• PID : Уникальный идентификатор процесса.
• USER : Владелец процесса.
• PR : приоритет процесса.
• NI : NICE значение процесса.
• VIRT : Сколько виртуальной памяти используется процессом.
• RES : Сколько физической памяти используется процессом.
• SHR : сколько общей памяти используется процессом.
• S : У казывает на состояние процесса: S = сон R = работает Z = зомби.
• %CPU : Процент процессора, используемого процессом.
• %MEM : Процент оперативной памяти, используемой процессом.
• TIME+ : Как долго работает процесс.
• COMMAND : Наименование процесса.

Если вы хотите увидеть полный путь к команде вместо ее имени, запустите следующий формат команды top:

# top -b | head -50 top — 12:16:41 up 57 days, 22:02, 3 users, load average: 1.98, 1.77, 1.83 Tasks: 309 total, 1 running, 216 sleeping, 0 stopped, 0 zombie %Cpu(s): 3.0 us, 4.5 sy, 0.0 ni, 92.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 16400812 total, 257304 free, 3169012 used, 12974496 buff/cache KiB Swap: 0 total, 0 free, 0 used. 13556452 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 18002 root 20 0 0 0 0 I 6.2 0.0 0:00.03 kworker/2:3-mm_ 18955 root 20 0 162180 4496 3820 R 6.2 0.0 0:00.01 top 26826 root 20 0 639508 524456 57648 S 6.2 3.2 1346:12 kube-controller 28494 root 20 0 1515256 1.3g 52140 S 6.2 8.1 7619:00 kube-apiserver 1 root 20 0 129568 9180 5252 S 0.0 0.1 152:30.38 systemd 2 root 20 0 0 0 0 S 0.0 0.0 0:01.77 kthreadd 3 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_gp 4 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 rcu_par_gp 6 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/0:0H-kb 8 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 mm_percpu_wq 9 root 20 0 0 0 0 S 0.0 0.0 6:30.09 ksoftirqd/0 10 root 20 0 0 0 0 I 0.0 0.0 131:34.56 rcu_sched 11 root rt 0 0 0 0 S 0.0 0.0 0:37.83 migration/0 13 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/0 14 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/1 15 root rt 0 0 0 0 S 0.0 0.0 0:36.70 migration/1 16 root 20 0 0 0 0 S 0.0 0.0 4:50.88 ksoftirqd/1 18 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/1:0H-kb 19 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/2 20 root rt 0 0 0 0 S 0.0 0.0 0:36.68 migration/2 21 root 20 0 0 0 0 S 0.0 0.0 5:33.97 ksoftirqd/2 23 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/2:0H-kb 24 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuhp/3 25 root rt 0 0 0 0 S 0.0 0.0 0:35.79 migration/3 26 root 20 0 0 0 0 S 0.0 0.0 6:43.59 ksoftirqd/3 28 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kworker/3:0H-kb 29 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kdevtmpfs 30 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 netns 31 root 20 0 0 0 0 S 0.0 0.0 0:13.96 kauditd 32 root 20 0 0 0 0 S 0.0 0.0 0:12.74 khungtaskd 33 root 20 0 0 0 0 S 0.0 0.0 0:00.00 oom_reaper 34 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 writeback 35 root 20 0 0 0 0 S 0.0 0.0 0:00.47 kcompactd0 36 root 25 5 0 0 0 S 0.0 0.0 0:00.00 ksmd 37 root 39 19 0 0 0 S 0.0 0.0 0:20.81 khugepaged 130 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kintegrityd 131 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 kblockd 132 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 blkcg_punt_bio 133 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 tpm_dev_wq 134 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 md 135 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 edac-poller 136 root 0 -20 0 0 0 I 0.0 0.0 0:00.00 devfreq_wq 137 root rt 0 0 0 0 S 0.0 0.0 0:00.00 watchdogd

2) Как найти процесс с высокой загрузкой процессора в Linux с помощью команды ps

ps обозначает processes status, она отображает информацию об активных / запущенных процессах в системе.

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

# ps -eo pid,ppid,%mem,%cpu,cmd —sort=-%cpu | head PID PPID %MEM %CPU CMD 18527 1714 4.2 40.3 /usr/lib/firefox/firefox -contentproc -childID 18 -isForBrowser -prefsLen 10002 -prefMapSize 213431 -parentBuildID 20191031132559 -greomni /usr/lib/firefox/omni.ja -appomni /usr/lib/firefox/browser/omni.ja -appdir /usr/lib/firefox/browser 1714 true tab 1714 1152 5.6 8.0 /usr/lib/firefox/firefox —new-window 18324 1714 4.9 6.3 /usr/lib/firefox/firefox -contentproc -childID 16 -isForBrowser -prefsLen 10002 -prefMapSize 213431 -parentBuildID 20191031132559 -greomni /usr/lib/firefox/omni.ja -appomni /usr/lib/firefox/browser/omni.ja -appdir /usr/lib/firefox/browser 1714 true tab 3286 1714 2.0 5.1 /usr/lib/firefox/firefox -contentproc -childID 14 -isForBrowser -prefsLen 8078 -prefMapSize 213431 -parentBuildID 20191031132559 -greomni /usr/lib/firefox/omni.ja -appomni /usr/lib/firefox/browser/omni.ja -appdir /usr/lib/firefox/browser 1714 true tab 1783 1714 3.0 4.5 /usr/lib/firefox/firefox -contentproc -childID 1 -isForBrowser -prefsLen 1 -prefMapSize 213431 -parentBuildID 20191031132559 -greomni /usr/lib/firefox/omni.ja -appomni /usr/lib/firefox/browser/omni.ja -appdir /usr/lib/firefox/browser 1714 true tab 1227 1152 2.3 2.5 /usr/bin/gnome-shell 1170 1168 3.5 2.2 /usr/lib/Xorg vt2 -displayfd 3 -auth /run/user/1000/gdm/Xauthority -nolisten tcp -background none -noreset -keeptty -verbose 3 16865 1714 2.5 2.1 /usr/lib/firefox/firefox -contentproc -childID 15 -isForBrowser -prefsLen 10002 -prefMapSize 213431 -parentBuildID 20191031132559 -greomni /usr/lib/firefox/omni.ja -appomni /usr/lib/firefox/browser/omni.ja -appdir /usr/lib/firefox/browser 1714 true tab 2179 1714 2.7 1.8 /usr/lib/firefox/firefox -contentproc -childID 6 -isForBrowser -prefsLen 7821 -prefMapSize 213431 -parentBuildID 20191031132559 -greomni /usr/lib/firefox/omni.ja -appomni /usr/lib/firefox/browser/omni.ja -appdir /usr/lib/firefox/browser 1714 true tab

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

# ps -eo pid,ppid,%mem,%cpu,comm —sort=-%cpu | head PID PPID %MEM %CPU COMMAND 18527 1714 4.1 40.4 Web Content 1714 1152 5.7 8.0 firefox 18324 1714 4.9 6.3 Web Content 3286 1714 2.0 5.1 Web Content 1783 1714 3.0 4.5 Web Content 1227 1152 2.3 2.5 gnome-shell 1170 1168 3.5 2.2 Xorg 16865 1714 2.4 2.1 Web Content 2179 1714 2.7 1.8 Web Content

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

Источник: itsecforu.ru