Как узнать что грузит процессор linux

Как узнать, что грузит систему?

Ребята. Такое дело. Ежедневно в более-менее определённые часы один процесс прилично грузит процессор, причём по cpu system т.е. это какой-то системный вызов. Так вот очень нужно узнать какой. Но поскольку я ленив, то с strace сидеть не хочу. Хочется автоматизации и минимум телодвижений. Спасибо! p.s. ос убунту-сервер трасти

Я знаю какой процесс грузит мне систему и характер нагрузки тоже знаю — cpu system. Мне нужно знать какой это системный вызов.

Простите, действительно не понял. Я все еще удивлялся такой вопрос и при этом про strace пишите 🙂

Напиши скрип, который будет отслеживать нагрузку на CPU, при обнаружении злостного процесса, запустит strace -p $PIDOFBADPROC -o /path/to/log/file .

Бывает 🙂 Просто есть процесс который каждый день в определённое время грузит мне проц под 100% и это именно cpu system. Причём в это время он делать ничего не должен (приложение сетевое и трафика там почти ноль, чнн приходится совсем на другое время), потом нагрузка резко падает. Вот я и хочу узнать, чего ему так надо от ядра.

Специалисты знают разницу между процессом и system call, а ты дальше HR не пройдешь.

есть скрипт, раз в 3-4 часа он выполняет операции, задействуя несколько процессов, всё это будет в статистике atop.

Источник

unixforum.org

Форум для пользователей UNIX-подобных систем

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

Модератор: Bizdelnick

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

Сообщение CityAceE » 04.10.2007 07:04

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

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

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

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

Сообщение m@key » 04.10.2007 10:12

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

Сообщение CityAceE » 05.10.2007 01:16

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

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

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

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

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

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

Сообщение pktfag » 05.10.2007 01:39

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

Сообщение CityAceE » 05.10.2007 03:05

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

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

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

Сообщение DaemonTux » 05.10.2007 06:42

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

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

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

Сообщение vr13 » 05.10.2007 07:34

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

в вашем случае, скрипт, инициирующий бигля, скорее всего находится в /etc/cron.daily. найдите его и посмотрите в чем дело. править ничего не надо, скорее всего просмотр файла даст вам идею, где искать настройки

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

опять же в opensuse, механически сделано так: в каталоге /etc/beagle есть набор файлов crawl-*, в которых по сути перечисляются директории, которые надо индексировать (CRAWL_PATHS) и опции бигля (ENABLE, RECURSE). все это в переменных окружения (environment vars), которые устанавливают поведение бигля. соответственно, в конечном счете нужно подправить переменные. в ubuntu думаю что-то в этом роде

Источник

Высокая загрузка процессора системой в Linux. Как узнать почему?

<sub>(источник: joxi.ru)

(источник: joxi.ru)</sub>

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

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

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

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

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

2 ответа 2

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

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

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

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

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

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

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

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

Источник

Как узнать загрузку процессора и памяти в Linux — команда vmstat

Производительность (или непроизводительность) систем очень сложно оценивать «на глаз» или даже с секундомером. Ведь даже если это и получится, то из виду будут упущены ключевые детали, предоставляющие информацию о том, почему производительность может быть именно такой, а не больше (или меньше). Для выяснения причин стоит углубиться в анализ этой самой производительности более основательно. И для этих целей существуют специализированные утилиты, одной из которых является vmstat – довольно популярный инструмент (после команды top разве что), которым пользуются многие системные администраторы Linux.

Как нужно оценивать производительность?

Вообще, производительность и/или быстродействие — величины постоянные только для конкретного (и довольно короткого) промежутка времени для конкретной системы. Для более объективной оценки необходимо проводить многочисленные «замеры» в разное время в течении довольно длительного (месяц и более) периода.

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

Синтаксис команды vmstat

Утилитой vmstat можно анализировать не только использование процессора, но также память — оперативную и/или дисковую. Синтаксис команды следующий:

Основными аргументами являются delay – время (в секундах), в течение которого следует производить замер, а также count – количество замеров или отчётов. Если дать команду vmstat без указания количества замеров, то она будет выводить отчёты, пока не будет прервано её выполнение сочетанием клавиш .

Вывод vmstat разбит на столбцы, которые объединены в следующие категории:

• procs – информация о процессах;
• memory – состояние оперативной памяти;
• swap – состояние виртуальной памяти (раздел или файл подкачки);
• io – активность устройств хранения (диски, флешки и т. д.);
• system – общая активность системы;
• cpu – использование центрального процессора.

Как уже было отмечено выше, эти категории объединяют колонки из вывода vmstat по соответствующему типу информации. Стоит рассмотреть их по отдельности. Для раздела procs:

• r – количество процессов в обрабатываемой процессором очереди;
• b – количество процессов, стоящих в очереди на выполнение операций ввода/вывода.

Для раздела memory:

• free – размер свободной памяти. То же значение, которое определяется командой free;
• swpd – количество блоков, которые были перемещены в Swap;
• buff – буферы памяти;
• cache – кеш памяти.

• si – общее количество блоков, считываемых системой из Swap;
• so – общее количество блоков, перемещаемых системой в Swap.

• bi – количество блоков в секунду, считываемых с диска;
• bo – количество блоков в секунду, записанных на диск.

• in – частота (количество в секунду) системных прерываний;
• cs – частота переключений между задачами.

• us – используемое (в процентах) время для выполнения «пользовательских» (т. е. не принадлежащих ядру) задач;
• sy — используемое (в процентах) время для выполнения задач ядра;
• id – время (в процентах) в простое;
• wa — время (в процентах), отведённое на ожидание операций ввода/вывода.

Опции vmstat

Доступные для vmstat опции приведены в следующей таблице:

Примеры использования vmstat

Несмотря на то, что опции vmstat и позволяют получить ценные сведения, однако в большинстве случаев системные администраторы их практически не используют. Чаще всего использование vmstat сводится к следующему (что вполне достаточно):

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

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

Заключение

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

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник