Linux top cpu больше 100

Обновлено: 08.07.2024

Объем памяти, размер кеша, скорость чтения и записи на диск, скорость и доступность вычислительной мощности – это ключевые элементы, влияющие на производительность любой инфраструктуры.

Данное руководство ознакомит с базовыми понятиями мониторинга CPU. Вы узнаете, как использовать утилиты uptime и top, чтобы узнать о нагрузке и использовании ЦП.

Требования

Сервер Linux.
Утилиты uptime и top должны быть установлены по умолчанию. Если это не так, установите их вручную.

Основные понятия

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

Загрузка и использование ЦП

Загрузка (CPU Load) и использование процессора (CPU Utilization) – два разных способа взглянуть на использование вычислительной мощности компьютера.

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

Использование ЦП оценивает исключительно занятость кассиров и не знает, сколько клиентов в очереди.

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

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

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

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

Ненормированные и нормированные значения

В одной процессорной системе общая емкость всегда равна 1. В многопроцессорной системе данные могут отображаться двумя разными способами. Суммарная емкость всех процессоров рассчитывается как 100% независимо от количества процессоров, такое значение считается нормированным. Другой вариант предлагает считать каждый процессор как единицу, так что 2-процессорная система в полном объеме имеет емкость 200%, 4-процессорная система в полном объеме имеет мощность 400% и т. д.

Чтобы правильно интерпретировать загрузку или использование CPU, нужно знать количество процессоров на сервере.

Отображение информации о ЦП

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

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

Знание точного количества процессоров важно для интерпретации результатов тех или иных утилит.

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

Оптимальное значение использования ЦП зависит от того, какую работу должен выполнять сервер. Стабильно высокое использование процессора негативно влияет на отзывчивость системы. Часто приложениям и пакетным заданиям с интенсивными вычислениями необходим весь или почти весь объем ЦП. Однако, если система должна обслуживать веб-страницы или поддерживать интерактивные сеансы сервисов (например, SSH), тогда может понадобиться свободная вычислительная мощность.

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

Мониторинг ЦП

Существует множество инструментов для получения данных о состоянии ЦП системы. Мы рассмотрим две команды: uptime и top. Обе утилиты являются частью стандартной установки большинства популярных дистрибутивов Linux и обычно используются для исследования загрузки и использования ЦП.

Примечание: Следующие примеры выполнены на 2-ядерном сервере.

Утилита uptime

Команда uptime позволяет отследить загрузку процессора. Она может быть полезна, если система медленно реагирует на интерактивные запросы (вероятно, ей не хватает системных ресурсов).

Утилита uptime сообщает следующие данные:

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

uptime
14:08:15 up 22:54, 2 users, load average: 2.00, 1.37, 0.63

В этом примере команда была запущена в 14:08 на сервере, который работал почти 23 часа. При запуске uptime подключились два пользователя. Этот сервер имеет 2 процессора. За минуту до запуска команды средняя загрузка процессора была 2,00, что означает, что в течение этой минуты процессоры использовали в среднем две задачи, а ожидающих задач не было. Среднее значение загрузки з а5 минут указывает на то, что в течение некоторого интервала времени один из процессоров бездействовал около 60% времени. Среднее за 15 минут значение указывает на то, что было доступно больше времени обработки. Вместе эти три значения показывают увеличение загрузки за последние пятнадцать минут.

Утилита uptime сообщает полезные средние значения загрузки ЦП, но для того, чтобы получить более подробную информацию, нужно использовать top.

Утилита top

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

Заглавный блок

Первые пять строк содержат сводную информацию о процессах на сервере:

top - 18:31:30 up 1 day, 3:17, 2 users, load average: 0.00, 0.00, 0.00
Tasks: 114 total, 1 running, 113 sleeping, 0 stopped, 0 zombie
%Cpu(s): 7.7 us, 0.0 sy, 0.0 ni, 92.2 id, 0.0 wa, 0.0 hi, 0.0 si, 0.1 st
KiB Mem : 4046532 total, 3238884 free, 73020 used, 734628 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 3694712 avail Mem

Первая строка почти идентична выводу утилиты uptime. Здесь показаны средние значения за одну, пять и пятнадцать минут. Эта строка отличается от вывода uptime только тем, что вначале указывается утилита top и время последнего обновления данных.

Вторая строка предоставляет краткий обзор состояния задач: общее количество процессов, количество запущенных, спящих, остановленных и зависших процессов.

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

Четвертая и пятая строки сообщают об использовании памяти и swap соответственно.

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

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

top - 14:36:05 up 23:22, 2 users, load average: 2.77, 2.27, 1.91
Tasks: 117 total, 3 running, 114 sleeping, 0 stopped, 0 zombie
%Cpu(s): 98.3 us, 0.2 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.2 si, 1.3 st
KiB Mem : 4046532 total, 3244112 free, 72372 used, 730048 buff/cache
KiB Swap: 0 total, 0 free, 0 used. 3695452 avail Mem
. . .

Давайте рассмотрим подробнее все компоненты строки CPU.

us, user: время на un-niced процессы пользователя. Эта категория относится к пользовательским процессам, которые были запущены без явного приоритета планирования. Системы Linux используют команду nice для установки приоритета планирования процесса. «un-niced» означает, что приоритет по умолчанию не менялся с помощью nice. Значения user и nice учитывают все пользовательские процессы. Высокое использование ЦП в этой категории может указывать на неконтролируемый процесс. Вывод в таблице процессов может определить, действительно ли это так.
sy, system: системные процессы. Большинство приложений имеют как пользовательские компоненты, так и компоненты ядра. Когда ядро Linux создает системные вызовы, проверяет привилегии или взаимодействует с устройствами от имени приложения, здесь отображается использование процессора. Когда процесс выполняется не ядром, он будет отображаться либо в показателе user, либо в nice, если его приоритет был задан с помощью nice.
ni, nice: niced процессы пользователя. Как и user, это поле отображает задачи, не связанные с ядром. В отличие от user, приоритет планирования для этих задач был установлен с помощью nice. Уровень приоритета (niceness) процесса указан в четвертом столбце таблицы процессов в заголовке NI. Процессы со значением niceness от 1 до 20 имеют пониженный приоритет. Такие процессы, потребляющие много процессорного времени, обычно не создают проблем, потому что задачи с повышенным приоритетом получат вычислительную мощность своевременно. Однако, если задачи с повышенным приоритетом (между -1 и -20) занимают непропорциональное количество CPU, они могут легко повлиять на отзывчивость системы. Обратите внимание, что многие процессы с самым высоким приоритетом планирования (-19 или -20 в зависимости от системы) порождаются ядром для выполнения важных задач, которые влияют на стабильность системы. Если вы не уверены, что точно знаете все процессы, указанные в выводе, лучше исследуйте их, но не останавливайте.
Id, idle: время, затраченное на обработчик простоя ядра. Этот показатель отображает процент времени, в течение которого ЦП был доступен и простаивал. Считается, что система разумно использует ЦП, если сумма user, nice и idle близка к 100%.
wa, IO-wait: время ожидания завершения ввода-вывода. Показатель сообщает, когда процессор начал операцию чтения или записи и ожидает завершения операции ввода-вывода. Задачи чтения и записи для удаленных ресурсов (таких как NFS и LDAP) будут также учитываться. Как и в строке idle, прыжки здесь считаются нормой. Но если показатель сообщает о частых или продолжительных обработках, это может указывать на зависшую задачу или потенциальную проблему с жестким диском.
hi: время на бслуживание аппаратных прерываний. Это время, затрачиваемое на физические прерывания, отправленные на процессор с периферийных устройств (дисков и аппаратных сетевых интерфейсов). Если значение аппаратного прерывания велико, одно из периферийных устройств может работать неправильно.
si: время, затраченное на обслуживание программных прерываний. Программные прерывания отправляются процессами, а не физическими устройствами. В отличие от аппаратных прерываний, которые происходят на уровне ЦП, программные прерывания происходят на уровне ядра. Если этот показатель сообщает о высоком использовании вычислительной мощности, исследуйте процессы, которые используют CPU.
st: время, которое использовал гипервизор. Значение steal сообщает, как долго виртуальный процессор ожидает ответа физического процессора, когда гипервизор обслуживает свои задачи или другой виртуальный процессор. По сути, объем использования ЦП в этом поле указывает, сколько мощности для обработки виртуальной машины готово к использованию, но недоступно приложению, поскольку оно используется физическим хостом или другой виртуальной машиной. Как правило, нормой значения steal считается до 10% в течение коротких периодов времени. Большее значение steal в течение более длительного периода времени указывает на то, что физический сервер имеет больший спрос на CPU, чем он может предоставить.

Таблица процессов

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

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9966 8host 20 0 9528 96 0 R 99.7 0.0 0:40.53 stress
9967 8host 20 0 9528 96 0 R 99.3 0.0 0:40.38 stress
7 root 20 0 0 0 0 S 0.3 0.0 0:01.86 rcu_sched
1431 root 10 -10 7772 4556 2448 S 0.3 0.1 0:22.45 iscsid
9968 root 20 0 42556 3604 3012 R 0.3 0.1 0:00.08 top
9977 root 20 0 96080 6556 5668 S 0.3 0.2 0:00.01 sshd
.

Столбец %CPU представлен как процентное значение, но он не нормируется, поэтому в этой двухъядерной системе общее количество всех значений в таблице процессов должно составлять до 200%, если оба процессора полностью используются.

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10081 8host 20 0 9528 96 0 R 50.0 0.0 0:49.18 stress
10082 8host 20 0 9528 96 0 R 50.0 0.0 0:49.08 stress
1439 root 20 0 223832 27012 14048 S 0.2 0.7 0:11.07 snapd
1 root 20 0 39832 5868 4020 S 0.0 0.1 0:07.31 systemd

Заключение

Теперь вы умеете работать с утилитами uptime и top и интерпретировать их вывод.

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

Давайте разберем значение каждой из строк.

load average: 0,00, 0,01, 0,05
В этой части показывается средняя нагрузка; она может сбивать с толку, особенно на виртуальной машине/в облаке.
Первая цифра показывает среднюю нагрузку «последней минуты», или «текущую» среднюю нагрузку; вторая цифра показывает «среднюю нагрузку за 5 минут», последняя цифра – «среднюю нагрузку за 15 минут».
Средняя нагрузка – мера среднего числа процессов, ожидающих своей очереди, чтобы совершить какое-либо действие в процессоре. Как и в супермаркете, приходится стоять в очереди, дожидаясь, пока кассир уделит вам все свое внимание. Причина, по которой средняя нагрузка растет, заключается в остальной статистике и счетчиках, находящихся ниже этой линии, поэтому, если ориентироваться строго на значения средней нагрузки, можно не увидеть всей картинки полностью.

Вот пример, взятый из узла distcc:

Данный сервер, кроме того, что является средой промежуточной обработки для скриптов и хостингом инструментов командной строки облака, предоставляет также распределенную службу C компилятора различным машинам, находящимся в нашей сети, поскольку она имеет 8 процессоров, 32 ГБ оперативной памяти и тонну псевдодискового пространства. При нормальной нагрузке, среднее ее значение остается относительно низким; при выполнении java-скриптов нагрузка может вырастать в два и более раза. Однако при выполнении службы компилятора при полной нагрузке (10 выполняемых процессов при загрузке процессора, равной 95% или выше), среднее значение нагрузки составляет 0,75… Как же так получается? Попытаемся разобраться

Строка Tasks

Tasks: 119 total, 1 running, 118 sleeping, 0 stopped, 0 zombie
Tasks: показывает количество процессов, когда вы набираете, например, “ps aux”.
• total Общее количество задач полезно знать для выявления вышедшего из-под контроля сервера apache или экземпляра postgresql, но оно обычно остается достаточно стабильным.
• running Количество запущенных процессов показывает вам, как в настоящее время используется ваш процессор. Приложения, не имеющие многопоточности, за один раз, как правило, могут использовать 1 процессор, поэтому обычным делом является ситуация, когда 1 процесс использует 25% процессора четырехъядерного сервера со средней нагрузкой

1.
• sleeping Количество ждущих процессов показывает, какие процессы выполняются, но не являются активными; обычно это фоновые задачи, системное ПО, драйвера принтера и т.д.
• stopped Количество остановленных процессов должно, как правило, равняться 0, если вы не послали процессу сигнал a SIGSTOP или kill -STOP для устранения неисправностей. Если это число отличается от 0, то, в случае с рабочими серверами это может служить поводом для беспокойства.
• zombie Зависшие процессы. Это означает, что многопоточное приложение запустило дочерний процесс, а затем было уничтожено или неожиданно завершено, оставив после себя повисший процесс, известный, как zombie-процесс. Apache может наплодить целую кучу таких процессов в случае, если происходит что-то из ряда вон выходящее. Обычно, их число тоже должно равняться 0.

Строка Cpu

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

0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Второй набор значений связан с виртуализацией, и именно по ним мы можем точно отследить те проблемы, которые, возможно, вносят вклад в высокое значение средней нагрузки.

• %wa – iowait, процент времени (циклов, секунд), в течение которого процессор простаивал, ожидая завершения операции ввода-вывода. Когда какой-либо процесс или программа запрашивает данные, он сначала проверяет кэш процессора (в нем имеется 2 или 3 кэша), затем проверяет память и, наконец, доходит до диска. Дойдя до диска, процессу или программе обычно приходится ждать, пока поток ввода-вывода передаст информацию в оперативную память, прежде чем иметь возможность снова на нем работать. Чем медленнее диск, тем выше будет значение IO Wait % для каждого процесса. Это происходит также с процессами записи на диск, если системный буфер заполнен и его необходимо прочистить при помощи ядра – обычно это наблюдается на серверах баз данных с высокой нагрузкой. Если значение IO Wait стабильно превышает %, это означает, что, возможно, имеется проблема хранения, с которой необходимо разобраться. Если вы наблюдаете высокую среднюю нагрузку, прежде всего, проверьте этот параметр. Если он высок, тогда узкое место в процессах, скапливающихся на диске, а не в чем-либо еще.
• %hi означает прерывания на уровне железа; на плате электроны движутся по микросхемам предсказуемым образом. Например, когда сетевая карта получает пакет, перед передачей информации, содержащейся в пакете в процессор через ядро, она запросит прерывание в канале прерывания материнской платы. Процессор сообщает ядру, что у сетевой карты для него есть информация, а ядро имеет возможность решить, как поступить. Высокое значение времени, тратящегося на обработку прерываний на уровне железа встречается на виртуальной машине довольно редко, но по мере того, как гипервизоры предоставляют в распоряжение виртуальных машин все больше «железа», эта ситуация может измениться. Чрезвычайно высокая пропускная способность сети, использование USB, вычисления на графических процессорах, — все это может привести к росту этого параметра на величину, превышающую несколько процентов.
• %si – прерывание на уровне софта; в ядре linux версии 2.4 реализована возможность запроса прерывания программным обеспечением (приложениями), а не элементом аппаратного обеспечения или устройством (драйвером), запрашивающим прерывание в канале прерывания материнской платы; запрос обслуживается ядром посредством его обработчика прерываний. Это означает, что приложение может запросить приоритетный статус, ядро может подтвердить получение команда, а программное обеспечение будет терпеливо ждать, пока прерывание не будет обслужено. Если мы применим утилиту tcpdump к гигабитному каналу с высоким трафиком, то значение может измениться примерно на 10%, — по мере заполнения выделенной памяти tcpdump, утилита посылает зарос на прерывание, чтобы переместить данные со стека на диск, экран, или куда угодно еще.
• %st — самый важный параметр из всех в списке, по моему мнению, это IOSteal%. В виртуализированной среде множество логических серверов могут работать под одним фактическим гипервизором. Каждой виртуальной машине(VM) мы присваиваем 4-8 «виртуальных» CPU; хотя сами гипервизоры могут не иметь (кол-во VM * кол-во виртуальных CPU на одну VM). Причина этого заключается в том, что мы не перегружаем CPU использованием наших виртуальных машин, так что если мы дадим одной-двум VM возможность изредка использовать 8 процессоров, это не будет негативно влиять на весь пул в целом. Однако если виртуальными процессорами VM используется количество CPU, превышающее количество физических (или логических, в случае с гиперпотоковыми процессорами Xeon), тогда значение iosteal будет расти.

iosteal% — мера загруженности гипервизора; наличие в каком-либо пуле виртуальных машин, демонстрирующих стабильно высокое значение параметра iosteal% (более 15%) может свидетельствовать о необходимости переноса некоторых из VM в другую часть пула.

iowait% является показателем производительности диска. В системе хранения данных, поддерживаемой NetApp, у нас может не получиться решить проблему производительности без перемещения тома на менее используемый, или другой диск NetApp. В случае с локальным диском (SSD или SAS) это может означать, что в гипервизоре имеется слишком много VM, интенсивно использующих ресурсы диска, и может потребоваться перенести некоторые из этих VM в другую часть пула.

Подведем итоги:

• Средняя нагрузка, на самом деле, ни о чем не говорит.
• Параметр %userland (%us) важен для средней нагрузки, поскольку он говорит о том, что производятся вычисления. Например, mysql, займет всего один поток, поэтому при полной нагрузке будет использовать (1/кол-во виртуальных CPU, присвоенных VM). postgresql является многопоточным, и может использовать больше процессоров, если они будут выделены, – помните об этом, создавая виртуальные машины в гипервизоре, чтобы предотвратить:
• %st – iosteal% — показатель загруженности гипервизора. Создание стека из 4-х postgresql и 6 серверов tomcat под одним гипервизором может быть разумным с точки зрения бизнеса, но вам придется все время конкурировать за процессорное время.
• %wa – iowait% — показатель количества времени, которое уходит на отсылку ваших процессов на невероятно медленные диски, неважно какое решение для хранения данных вы используете. Диски, даже SSD, сравнительно медленные. Добавление ОЗУ для увеличения буфера ядра может немного смягчить проблему. ОЗУ дешевле диска, если учесть, насколько молниеносно она работает по сравнению с ним.

Дополнительные команды

iostat
Если вы столкнулись с высокими значениями параметров iowait или iosteal, можно с точностью отследить, какой диск является этому причиной, при помощи команды iostat. Запускается она таким образом:

Более подробно, см. руководство по iostat. Разбивка, выводимая каждую секунду, с каких и на какие диски идет чтение/ запись, а также все значения iosteal или iowait, связанные с доступом к этим дискам.

htop
Команда по использованию CPU и процессов на системе Linux. Он не показывает виртуальную статистику, но отображает дерево процессов, а также разбивку каждого процессора в системе, его использование; кроме того, он показывает статистику свопинга и памяти, позволяющую отследить неприятные утечки памяти, раскрашивая все это симпатичными цветами. По моему мнению, этот пакет должен быть обязательным для всех VM.

Иногда имеем высокую загрузку процессора некими системными задачами.
Не процессами из userland, а именно "система" грузит.
Т.е. явно выполняются какие-то системные вызовы (выделение памяти, переключения контекста), или работают драйверы (обрабатывают прерывания или что-то еще), идёт активный ввод-вывод.

Это всё я всегда предполагаю, Но как узнать ТОЧНО, почему высокая загрузка - не представляю. Поэтому прошу помощи.

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

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

Вот хочется найти какое-нибудь средство быстро и точно узнавать что же грузит процессор.

что значит "система" грузит? примеры ваших процессов приведите? что для вас "быстро"? если процесс выдает 100% нагрузку в течении 0.5 секунд, с частотой 3 секунды? если раз в минуту грузит 100% на 10 секунд? "быстро" зависит от периода, который конкретно для вас слишком долгий Сорри, ещё не знаю тут как ответить конкретно человеку. Поэтому отпишу сразу всем: 1) Система - это поле sy в top. Или "красненькая" часть столбца в htop. Короче всё, что не user-space и не i/o. 2) Я рассматриваю сейчас случаи, когда 100% загрузка проца/ядра, и либо все эти 100% значатся как sys.load, либо часть как user, а часть как sys. 3) В основном меня начинает этот вопрос волновать когда эта нагрузка постоянна в течение как минимум часа и никуда не девается, и никак не коррелирует со входящим траффиком. Ну либо девается, когда убиваешь всё-всё-всё, гасишь обмен траффиком с сеткой. Результат vmstat уже показыватьно нет смысла. В этот раз причиной был DDOS с флудом TCP-пакетами на 80-й порт. И сетевушка просто захлёбывалась. Ядро даже не успевало забирать из её буфера пакеты. Но это я точно выяснил лишь когда хостер прикрыл траффик из инета кроме как от меня. Но не всегда есть такая возможность. Да и опять же. всё это косвенные способы. Я их знаю и умею. Но я хочу найти некую системную утилиту, которая показывает что там происходит под капотом у ядра. Чем оно грузит проц. Какой драйвер, прерывание от какого устройства, какой системный вызов. Ответить конкретно -- @имя (в одном комментарии допускается только одно). Смотреть статистику прерываний -- /proc/interrupt (вообще, man 5 proc -- полезное чтиво). А тут нагуглил кучу разных мониторов.

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

почитать про strace и подобные ему sudo strace -t -e trace=open,connect,accept unity сможете увидеть много интересного

для ядра - ftrace или поищите еще kernel tracer-ов

утилиты, которая дает понять это с одного взгляда я не знаю, если вы не нагуглите, я бы пошел следующим способом: настроить мониторинг процессов так, чтобы в случае возникновения нагрузки на K% на N секунд каким-либо процессом, он давал алерт.

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

Но тут нужно быть осторожным, чтобы не повалить систему и не заполнить hdd. Т.е. скриптинг должен учитывать, что необязательно ставить trace на процесс, который уже был под трейсом (т.е. для которого уже сохранен tracefile), иначе процессы начнут тормозить еще больше, к примеру. Нельзя трейсить слишком долго - гигабайтные дампы вам не нужны.

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

Т.е. тут все от задач зависит, дебажить драйвер ядра - один подход, защищаться от ddos - другой.

Что-то на 100% грузит CPU (Как узнать что именно?)

Для новичков как вообще в Linux, так и в конкретной теме, к которой относится вопрос.

Модератор: Bizdelnick

Что-то на 100% грузит CPU

В последние дни начал замечать, что утром (а всю ночь компьютер у меня качает файлы из Интернетеа) процессор загружен на 50% (или одно ядро на 100%). Когда захожу в монитор, то вижу что загрузка ядер процессора идёт попеременно и по-разному: то 20%+80%, то 65%+35%, а то и вовсе 0%+100%. В общем, соотношение разное, но сумма всегда равна 100%. При этом ни одного приложения не запущено. Сам монитор в списке запущенных приложений не показывает то, что так нагружает процессор. Запуск монитора через sudo хоть и выводит больше процессов, но именно тот, что загружает систему в списке отсутствует. Перегрузка компьютера помогает. Но это же не метод! Надо знать причину и устранять её.

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

Yes, I am a criminal. My crime is that of curiosity. My crime is that of
judging people by what they say and think, not what they look like.

Спасибо. Команда top выдала следующее:

А вот результат работы команды ps -aux:

Однако это привело меня в ступор. Во-первых, на моём компьютере нет других пользователей кроме "root" и "stanislav", а здесь процесс запущен от имени какого-то "beaglein". А во-вторых, в Интернете не могу найти никакой информации об "beagle-build-in".

Гадость какая-то непонятная.

Главное, не волноваться!
Это просто программа beagle создает кэш, для того, чтобы потом можно было быстро найти какие-нибудь данные на диске. Как мне кажется, она должна начинать кэшировать после 12 ночи. Можешь убить задание: в командной строке набрать kill -9 32620.
Вот ссылка на их сайт: Main Page - Beagle.
И пользователей на компе обычно куча. Смотреть их так можно less /etc/passwd.
Сейчас не могу дать ссылку на более подробное обьяснение, что эти за пользователи. beagle is the indexing thing (like google desktop)
I'm guessing this is the indexing process thats eating cpu like mad.

И даже смог убить процесс.

Но! Не нужно мне никакое индексирование! Я и так знаю где и что лежит у меня на компьютере. Вот бы суметь отключить навсегда этот самый beagle.

beagle is the indexing thing (like google desktop)
I'm guessing this is the indexing process thats eating cpu like mad.

И даже смог убить процесс.

бигль запускается по крону. и, вероятнее всего по system crontab (/etc/crontab), которая, грубо говоря, выполняет все, что находится в в /etc/cron.hourly, /etc/cron.daily, /cron/cron.weekly итд

в случае opensuse, это управляется yast. в случае ubuntu скорее всего тоже как-нить, "гуманоидно"

Читайте также: